- 1 名前：デフォルトの名無しさん mailto:sage [04/11/25 21:11:32]
- C++ のジェネリックプログラミングの話をしましょう。
以下のスレッドを統合するスレです。
STLスレッド
Part1 pc.2ch.net/tech/kako/1004/10042/1004287394.html
Part2 pc3.2ch.net/tech/kako/1026/10267/1026793823.html
【C++】Boost使い集まれ！
pc3.2ch.net/test/read.cgi/tech/1033830935/ (html化待ち?)
Generic Programming with C++ Template
pc.2ch.net/tech/kako/1008/10085/1008593126.html
【C++】template 統合スレ -- STL/Boost/Loki, etc.
pc2.2ch.net/tech/kako/1037/10377/1037795348.html
【C++】template 統合スレ -- Part2
pc2.2ch.net/test/read.cgi/tech/1047978546/ (html化待ち)
【C++】template 統合スレ -- Part3
pc5.2ch.net/test/read.cgi/tech/1066493064/ (html化待ち)
【C++】template 統合スレ -- Part4
pc5.2ch.net/test/read.cgi/tech/1083550483/ (html化待ち)
【C++】template 統合スレ -- Part5
pc5.2ch.net/test/read.cgi/tech/1091522597/
関連スレ、その他リンクは >>2-5 あたりに。
- 227 名前：デフォルトの名無しさん mailto:sage [05/01/10 18:13:13]
- www-6.ibm.com/jp/developerworks/linux/041203/j_l-cpregex.html
＞言語の機能 であるはずのものが、その言語のユーザーを恐れさせるようになったら、何かを変えるべき時なのです。
- 228 名前：デフォルトの名無しさん mailto:sage [05/01/10 18:13:59]
- >>226
それAssociative Container
- 229 名前：デフォルトの名無しさん mailto:sage [05/01/10 18:15:05]
- ここは
問題を無闇に複雑にして悦に浸る馬鹿のス靴（なぜか変換できない）
ですね。
- 230 名前：デフォルトの名無しさん mailto:sage [05/01/10 18:19:30]
- §23.2.4.3当たりだと見た。
- 231 名前：デフォルトの名無しさん mailto:sage [05/01/10 18:20:25]
- >>227>>229
またperlとかrubyの○キ信者ですか？
- 232 名前：デフォルトの名無しさん mailto:sage [05/01/10 18:23:27]
- boostが異常なのは認めなければなるまい。
昨今のC++は異常が常態。
- 233 名前：デフォルトの名無しさん mailto:sage [05/01/10 18:24:29]
- 確かに異常だが、使っているうちに快感になる。
- 234 名前：デフォルトの名無しさん mailto:sage [05/01/10 18:24:50]
- (23.1.1/7)と(23.2.4.3/3)読む限り>219でもOKっぽいですね
- 235 名前：デフォルトの名無しさん mailto:sage [05/01/10 18:27:46]
- CommonLispのようなわかりにくさを競い合って悦に浸るのがここの流儀
- 236 名前：デフォルトの名無しさん mailto:sage [05/01/10 18:28:39]
- >>234
OKだろ。個人的には俺はあまり書きたくないけど。
- 237 名前：デフォルトの名無しさん [05/01/11 00:57:13]
-
>>219
引くってのはどうよ。
for(element = test.begin(); element != test.end(); ++it)
{
if(*element == 2){
test.erase(element--);
}
}
あ、でも element = test.begin(); element--; は大丈夫なのかな。
まぁ、EffectiveSTLを読んでいれば test.erase(remove(),test.end())と書くというのに一票。
- 238 名前：237 [05/01/11 00:58:59]
- 訂正。
>>237
++it => ++element
- 239 名前：デフォルトの名無しさん mailto:sage [05/01/11 01:06:22]
- >>237 ダメ
- 240 名前：デフォルトの名無しさん mailto:sage [05/01/11 14:28:58]
- for(element = test.begin(); element != test.end(); ++element)
if(*element == 2)
{
element = --test.erase(element);
}
こんな感じが一番シンプルなところなのかな？
- 241 名前：デフォルトの名無しさん mailto:sage [05/01/11 15:04:23]
- removeとeraseの組み合わせが一番シンプル
- 242 名前：デフォルトの名無しさん mailto:sage [05/01/11 15:59:47]
- とりあえずremoveとeraseの組み合わせが何でも一番です（＾＾
- 243 名前：デフォルトの名無しさん mailto:sage [05/01/11 16:01:18]
- clearって手もあるよ
- 244 名前：デフォルトの名無しさん mailto:sage [05/01/11 19:46:02]
- >>223
プロジェクトって大抵いろんな技術レベルの人がいるから
その台詞でばっさりはちょっと抵抗あるなぁ。
一人でやるなら何使ったってOKだけどね。
- 245 名前：デフォルトの名無しさん mailto:sage [05/01/11 20:32:55]
- >>244
211はかなり基本だと思うんだけど...
- 246 名前：デフォルトの名無しさん mailto:sage [05/01/11 20:46:56]
- あれが解からないって？
…ときどき思うんだ。俺、なんで2chなんか見てるんだろう、って。
- 247 名前：237 [05/01/11 22:30:46]
- なんか不安になってきたので確認したいのですが
vectorのeraseで無効になるのは消した要素以降のイテレータですよね。
だから>>237と>>240は結果的に同じことになりますよね？
私が>>237で心配だったのは
最初の要素でヒットしたとき、
element = test.begin();
--element;
++element;
でbegin()に戻るのが規格で保証されてなさそう(多くの実装では戻りそうだけど)
というのと
元々のサイズが1のとき、test.erase(test.begin());で全てのイテレータが無効になる
ときにバッファを解放してbegin()とend()がNULLを返してくるようになるとend()と
永遠に一致しなそう(VC7のclearがバッファを解放(capacityを0)にしてくれるのに
気づいて以来疑り深くなっています)
の二点なんですけど、
そのあたりをふまえて>>239はダメと言っているんですよね？
うーん、remove(や類似のアルゴリズム)を使わないでやるならやはり>>219なのか。
- 248 名前：237 [05/01/11 22:34:15]
- ああ、そうか、後者の不安は>>240と書くことで払拭されるのか。
ｽﾏｿ
- 249 名前：244 mailto:sage [05/01/12 01:12:53]
- >>245
俺も基本だと思ってるし、これぐらいわかれよって思ってるよ。
でも、それが通用しないのが多人数でしょ？って投げかけ。
…技術と関係なくなるか。消えるよ。スレ汚しすまん。
- 250 名前：デフォルトの名無しさん mailto:sage [05/01/12 02:17:30]
- なぜforで回す……わざわざC++使うんだったら、効率にも気を
配らないともったいないよ。
>247
>237 >240の例だと
・ループごとにtest.end()の呼び出しが発生する
・elementを削除するたびにvectorの再パッケージが発生する
で遅くなりますな。
あと、>237だと後置インクリメントの一時オブジェクトの生成が
発生してさらに効率が悪くなります。
- 251 名前：デフォルトの名無しさん mailto:sage [05/01/12 02:18:18]
- なぜにremoveを使いたくないのかが知りたい
- 252 名前：250 mailto:sage [05/01/12 02:24:13]
- 自己フォロー
>237>240ともに、はelement==test.begin()のときに
*element==2だとアウトですな。
＃test.begin()よりも前に移動するから未定義の世界に突入
- 253 名前：デフォルトの名無しさん mailto:sage [05/01/12 02:48:28]
- >250
ループごとのtest.end()も後置インクリメントもここでは本質じゃない。
- 254 名前：デフォルトの名無しさん mailto:sage [05/01/12 02:56:25]
- >253
ふうん、じゃ、こう言っておこうかな
・郷に入れば郷に従え
STLはC++の一部なんだから、それぐらい覚えろ
・こんぐらいできないなら、そもそもC++使うな
or こんなこともできないやつをプロジェクトに入れるな
他にもPerlとか色々あるんだから、わざわざC++を使う必要ないよね。
- 255 名前：デフォルトの名無しさん mailto:sage [05/01/12 07:36:48]
- list に追加されている remove(),remove_if() 見習って、
template<class Container> void remove(Container&, typename Container::value_type const&)
template<class Container, class Predicate> void remove_if(Container&, Predicate p);
のような関数を作れば、双方文句はなかろう。
- 256 名前：255 mailto:sage [05/01/12 07:50:40]
- s/Container/Sequence/
remove() の意味が混乱を招きやすいという認識はSGIのドキュメントにも記載されている。
「慣用句だ」と言って押し切るよりは、むしろまともな認識だと思う。
www.sgi.com/tech/stl/remove_if.html#1
これをそのままソースに書いてしまうと言うのは、
例えば定数除算をシフトで書いてしまうのと同等の誤りであると思う。
- 257 名前：デフォルトの名無しさん [05/01/12 07:51:49]
-
forで回すからうっかり>>218とか>>237とか>>240とかいう問題のあるコードを書いて
しまうんだよ。
だったらおとなしくremoveを使えと。
まぁ、色々書き方があってその中から適切な物を状況に応じて選ぶのがプログラムの
醍醐味ではあるけど。
- 258 名前：デフォルトの名無しさん mailto:sage [05/01/12 08:53:47]
- ＞なぜにremoveを使いたくないのかが知りたい
叙述関数やoperator==とかにコードが分散するのがイヤ
ループが内包されるのがイヤ ループを制御下に置いておきたい
ブレイクポイントが設定しやすいよ
削除以外の用途にループが流用できるよ
てゆうかぶっちゃけremove_copy中でやってること、あれはありえないでしょ
それを言ったらvectorでeraseすること自体ありえないかｗ
- 259 名前：デフォルトの名無しさん mailto:sage [05/01/12 09:59:55]
- >ループが内包されるのがイヤ ループを制御下に置いておきたい
ループを明示的に書くより効率が良くなる可能性があるし、
コードの見通しも良くなる
- 260 名前：デフォルトの名無しさん [05/01/12 10:06:05]
- >>254
「理想郷」との差でしかモノを語れない
頭でっかちの引き籠もりはレスしなくていいです ;-)
- 261 名前：デフォルトの名無しさん mailto:sage [05/01/12 10:32:21]
- >260
それ、オレじゃない。人違いだ
- 262 名前：デフォルトの名無しさん [05/01/12 10:48:33]
- >260
IDくらい見ろ、ボケ！
- 263 名前：デフォルトの名無しさん mailto:sage [05/01/12 11:10:58]
- >>262
この板ID無いんだって気付よ！
- 264 名前：デフォルトの名無しさん mailto:sage [05/01/12 11:21:54]
- お前さんたちなんか楽しそうだね。
- 265 名前：デフォルトの名無しさん mailto:sage [05/01/12 11:42:25]
- IDの見方知らない香具師ってまだいたんだね
- 266 名前：デフォルトの名無しさん mailto:sage [05/01/12 12:13:29]
- はっきりいってvectorに限らず配列っぽいデータ構造を使っている時に
removeみたいなアルゴリズムを適用したくなることってあるか？
無理して適用しておもしろいことがあるようなものでもないと思うのだけど…
何か見落としている革新的な理由でもあったりするのだろうか？
- 267 名前：デフォルトの名無しさん mailto:sage [05/01/12 23:55:01]
- > removeみたいなアルゴリズムを適用したくなることってあるか？
配列から複数の要素を一度に取り除きたいときだな。
- 268 名前：デフォルトの名無しさん mailto:sage [05/01/13 00:11:28]
- 簡単
let remove x num = snd (List.partition (fun a -> a=x) num);;
- 269 名前：デフォルトの名無しさん [05/01/14 14:04:12]
- >>268
配列っぽくないデータ構造。
- 270 名前：デフォルトの名無しさん [05/01/15 01:33:25]
- >>267
そそ、端からeraseしてると効率悪いし、
効率的な処理にしようとすると意外に面倒。
- 271 名前：デフォルトの名無しさん mailto:sage [05/01/17 09:41:54 ]
- 俺も小さくて、しかもあまり使わないような関数を分散させるのが嫌いなんだけど、
「リファクタリング」を読むと、一行処理すら場合によっては関数にすることを推奨してるんだよな。
しっかりした関数名をつけることによって可読性が高まるって話なんだけど、
必ずしもそうとは思えないのは、英語圏ネイティブじゃないせいかね。
と、templateスレに書き込もうとしたのだけど、主旨に合わないのでこっちに投棄
- 272 名前：デフォルトの名無しさん mailto:sage [05/01/17 09:43:01 ]
- C++スレに書くつもりが…
もうどうでもいいや
- 273 名前：デフォルトの名無しさん mailto:sage [05/01/17 13:41:34 ]
- リファ〜に書いてあるのは関数じゃなくてメソッドのことでは
何の分類もしない単独の関数増やしてくのはあんま良いとは思えないが
メソッドの場合インターフェース抽出とか階層整理とかで意味がある
- 274 名前：272 mailto:sage [05/01/17 17:58:06 ]
- >>273
失礼、つい関数と呼んじまう。
インターフェース抽出や階層整理は、それ自体をメインにして行うべきな気がするんだよねぇ。
それどころかそれ以前で、非道い話だが「たくさんの、たった数行のメソッド」ってだけで、嫌悪感を感じてしまう。
いずれにせよスレ違い申し訳ない。
- 275 名前：デフォルトの名無しさん mailto:sage [05/01/18 00:41:35 ]
- >>273
そんな区別ないだろ。
少なくともC++ではthisポインタの有無しか違いはないわけで、
それが関数分けの基準に影響するとは思えない。
- 276 名前：デフォルトの名無しさん mailto:sage [05/01/18 01:35:22 ]
- 時々272のような人いるよね。
読むときあっちこっちの関数みないといけないから、とか言って。
このヘタレが
- 277 名前：デフォルトの名無しさん mailto:sage [05/01/18 01:45:39 ]
- そもそも行数とか関係ないだろ
- 278 名前：デフォルトの名無しさん mailto:sage [05/01/18 02:41:33 ]
- >275
その他にも可視性とアクセス範囲に違いがあるわけで……
- 279 名前：デフォルトの名無しさん mailto:sage [05/01/18 08:17:20 ]
- >>278
そうだな。
それらが要るならクラス作ってメンバ関数を作ればいいし、
要らないならフリー関数にしてもいい。
どう整理するかどうかが違うだけで、
処理に名前をつけてまとめたほうがよいかどうかの基準には関係ない。
複数のフリー関数を作った後に、さらに
それらをまとめてクラスを作ればよいことに気付くことも考えられる。
思い立ったらさっさと名前付けてまとめれ。
渋る意味がわからん。
- 280 名前：272 mailto:sage [05/01/18 08:20:53 ]
- ちとスレ違い悪いんでこっちでレス
pc5.2ch.net/test/read.cgi/tech/1099112338/41
- 281 名前：デフォルトの名無しさん mailto:sage [05/01/21 18:18:02 ]
- お聞きしたいのですが、
下記（次レス）のコードがVC7.1でコンパイルできませぬ。
どこがいけないのでしょうか…
色々実験してみた結果
・UINT を int にすると通る。
・UINT を std::size_t にしてもダメ。
・typename T を削除して、 boost::array の T を int とかにすると通る。
・boost:array の nSize を適当な数値で直打ちすると通る。
・bcc5.5.1 では普通に通る。
- 282 名前：281 [05/01/21 18:18:34 ]
- #include <boost/array.hpp>
typedef unsigned int UINT;
template<typename T, UINT nSize>
class A
{
typedef typename boost::array<T, nSize> tObjects;
typedef typename tObjects::iterator tObjectsIt;
tObjects m_cObjects;
public:
tObjectsIt Func();
};
// ↓C2244：関数の定義を既存の宣言と合致させることができませんでした。
template<typename T, UINT nSize>
inline typename A<T, nSize>::tObjectsIt A<T, nSize>::Func()
{
return m_cObjects.begin();
}
- 283 名前：デフォルトの名無しさん [05/01/21 20:49:28 ]
- >>281
手元にVC7.1もboostもないし、よくわからんけど、
コンパイラがバグってることはよくあるからｗ
- 284 名前：デフォルトの名無しさん mailto:sage [05/01/21 20:57:34 ]
- >>282
g++(3.3.3)ではなんの警告もエラーもなく通るのぅ……
- 285 名前：デフォルトの名無しさん mailto:sage [05/01/21 21:31:52 ]
- >>282
戻り値を素直に
typename boost::array<T, nSize>::iterator
とすると通りますね。
- 286 名前：デフォルトの名無しさん mailto:sage [05/01/22 00:57:24 ]
- typedefがprivateなのにinlineなのがいけないんじゃないのか？
と試してもないのに言ってみる
- 287 名前：281 mailto:sage [05/01/22 11:00:38 ]
- やはり、コンパイラが悪い方向なんですか… orz
なお、>>286を参考に、
すべてのメンバをpublic にしてみてもコンパイルが通りませんでした。
しょうがないので、現状では
・class内に直書き
・>>285 の方法
の２点で回避したいと思います。
どうもありがとうございました。
- 288 名前：デフォルトの名無しさん mailto:sage [05/01/22 11:27:55 ]
- いまだにちゃんと動かないコンパイラ多いのかよ
おまえらC++信用できますか？
- 289 名前：デフォルトの名無しさん mailto:sage [05/01/22 11:28:34 ]
- C++なら信用できるよ。
- 290 名前：デフォルトの名無しさん mailto:sage [05/01/22 15:39:27 ]
- >>282
vc8 でもダメっぽい
- 291 名前：デフォルトの名無しさん [05/01/23 15:44:13 ]
- boost::bindはstd::bind2ndとかより実行速度が落ちるって本当ですか？
- 292 名前：デフォルトの名無しさん mailto:sage [05/01/23 16:18:47 ]
- >>291
ためして、みなさいって。
- 293 名前：デフォルトの名無しさん mailto:sage [05/01/23 16:20:48 ]
- using句が,による複数引数を受け付けないのは何故ですか？
using A::AA, A::AB, A::AC;
のように出来たら便利だと思うのですが？
- 294 名前：デフォルトの名無しさん mailto:sage [05/01/23 17:06:31 ]
- 本スレの次スレ
【標準C++】C++相談室 part39【STL含む】
pc5.2ch.net/test/read.cgi/tech/1106466303/
- 295 名前：デフォルトの名無しさん mailto:sage [05/01/23 17:51:32 ]
- >>293
そんなんオレらに聞かれても困るよ
- 296 名前：デフォルトの名無しさん mailto:sage [05/01/23 17:57:05 ]
- >>293
プリプロセッサマクロを書くとか?
あんまり便利とも思えないけど
- 297 名前：デフォルトの名無しさん [05/01/23 22:42:53 ]
- boost(かSTL)に、次のような関数テンプレートって含まれていませんか？
template<typename T>
inline void assign(T& lhs, const T& rhs)
{
lhs = rhs;
}
次のような感じで、setterを用意していないメンバ変数(m_is_foo)を変更する関数オブジェクトを作るのに使いたいのです。標準であるならそっちを使いたいなと思いまして。
hoge(boost::bind(assign<bool>, boost::ref(m_is_foo), true));
- 298 名前：デフォルトの名無しさん mailto:sage [05/01/23 23:01:05 ]
- >>297
試してないけど、 hoge(boost::lambda::var(m_is_foo) = true) じゃだめ？
- 299 名前：297 mailto:sage [05/01/23 23:16:36 ]
- >>298
> 試してないけど、 hoge(boost::lambda::var(m_is_foo) = true) じゃだめ？
いけました。サンクスです。
うーん、lambdaか…。主観ですが実戦投入はちょっと怖いんですよね。
- 300 名前：デフォルトの名無しさん mailto:sage [05/02/07 09:18:51 ]
- ふぇ〜い
Boostを最新リリースにしたら＠VC6
_bvector.hでコンパイラが内部エラー起こしてビルドできない
Releaseビルドなら通った
コンパイラもしょっちゅう固まるし
やっぱ テンプレートをプリコンパイルヘッダにしたのが悪いのかな ・・
- 301 名前：デフォルトの名無しさん mailto:sage [05/02/07 09:23:19 ]
- 日記はMeadowにでｍ(ry
- 302 名前：デフォルトの名無しさん mailto:sage [05/02/07 09:28:51 ]
- >>300
ヘッダのインクルード順序を変えてみれ。
自分は面倒なので#ifとか使ってインクルード順序をすぐに変えられるようにしてる。
例：
#if 0 //ここを１にしたり0にしたりする。
#include <boost/regex.hpp>
#include <algorithm>
#else
#include <algorithm>
#include <boost/regex.hpp>
#endif
- 303 名前：デフォルトの名無しさん mailto:sage [05/02/07 14:42:53 ]
- Meta-Programming 専用のスレってない？
- 304 名前：デフォルトの名無しさん mailto:sage [05/02/07 17:41:03 ]
- あったけど、ここに統合。
- 305 名前：デフォルトの名無しさん [05/02/11 13:36:27 ]
- テンプレートを使ったクラスでundefined referenceがでます。
ソースは次のようなものです。プリプロセッサは省略してあります。
//temptest.h
template<class T> class temptest{
public:
temptest();
};
//temptest.cpp
template<class T> temptest<T>::temptest(){}
//main.cpp
int main(){
temptest<int> t;
return 0;
}
gccでは "undefined reference to `temptest<int>::temptest(void)"
VisualC++6では "public: __thiscall temptest<int>::temptest<int>(void)は未解決です"
というエラーです。
ちなみに定義をインラインにしたらうまくできました。
どなたか解決方法を教えてください。
- 306 名前：デフォルトの名無しさん mailto:sage [05/02/11 13:40:12 ]
- >>305
templateの定義はヘッダに書かないとダメ、ということになってます。
- 307 名前：304 mailto:sage [05/02/11 13:50:47 ]
- そんな決まりがあったんですか。
でもSTLのインクルードファイルを見たところ宣言だけのようですが、
STLは特別なんでしょうか。
- 308 名前：デフォルトの名無しさん mailto:sage [05/02/11 13:52:15 ]
- STLもヘッダの下のほうに書いてあるんじゃねーの
- 309 名前：デフォルトの名無しさん mailto:sage [05/02/11 13:52:42 ]
- STLも例外ではないよ
クラステンプレートに実体がなくてもその後ろにクラスメンバのテンプレートの実体が定義されてるはず
- 310 名前：デフォルトの名無しさん mailto:sage [05/02/11 14:13:29 ]
- stlportだとcppをヘッダからincludeしてたとおもう
- 311 名前：デフォルトの名無しさん mailto:sage [05/02/11 14:44:21 ]
- ヘッダからcppをインクルード・・・萌えるな。
- 312 名前：デフォルトの名無しさん mailto:sage [05/02/11 15:04:53 ]
- >>307
temptest.cpp コンパイル時には class T が何だか解らないので
コンストラクタは生成されない
↓
main.cpp コンパイル時には temptest<int> のコンストラクタが
どこかにあるものとしてコンパイル
↓
リンクしてみたら、どこにもいない
明示的にインスタンス化するよろし。
//temptest.cpp
template class temptest<int>;
- 313 名前：デフォルトの名無しさん mailto:sage [05/02/11 16:01:01 ]
- exportキーワードをまともに実装した処理系はComeau C++だけでしょ。
- 314 名前：デフォルトの名無しさん mailto:sage [05/02/11 19:41:42 ]
- もう諦めてexportを標準から外した方が良いんじゃないかとさえ思ったり．
現状，exportによる利得というのがほとんど無いみたいですし．
- 315 名前：デフォルトの名無しさん mailto:sage [05/02/11 21:11:04 ]
- つーか既に実装しなくていいよもう、ってことになったんじゃなかったか？
- 316 名前：デフォルトの名無しさん mailto:sage [05/02/11 21:50:10 ]
- >315
ソースきぼんぬ．
export周りは泣きそうなほどグダグダみたいですし，さもありなんですけど．
- 317 名前：デフォルトの名無しさん mailto:sage [05/02/11 22:10:19 ]
- それがC++クオリティ
- 318 名前：デフォルトの名無しさん mailto:sage [05/02/12 06:49:19 ]
- >>316
D&E日本語版読んでみ。
exportは未だに実装してないといけない規格になっている。
- 319 名前：デフォルトの名無しさん mailto:sage [05/02/12 19:42:14 ]
- exportって何？
- 320 名前：デフォルトの名無しさん mailto:sage [05/02/12 19:42:57 ]
- るｂｙ
- 321 名前：デフォルトの名無しさん mailto:sage [05/02/16 10:47:32 ]
- shared_ptrとかintrusive_ptrのリファレンスカウント操作って
引数で値渡しすると呼び出しのたびに操作しますよね。
最適化によるコード削減を阻害しないでしょうか?
特にテンプレートを展開したもののコードがどうなるかが気になります。
- 322 名前：デフォルトの名無しさん mailto:sage [05/02/16 11:26:01 ]
- >>321
適材適所で。
それからテンプレートの勉強もね。
- 323 名前：デフォルトの名無しさん mailto:sage [05/02/16 11:38:00 ]
- >>322 要するにオーバーヘッドはかかるというお答えという理解でよろしい?
intrusive_ptrの参照を渡せばいいんですけど、ポインタの置き換えに使うつもり
でいるといまひとつ面倒というか泥くさいというか。
あと、これらのコンテナをfor_eachなどで処理するときのbind(+lambda)で、
_1 と書くだけじゃdeductionしてくれず、bind(&HogePtr::get, _1)
のようにしないといけないのが面倒で、
これを何とか自動でやってくれるようにする方法はありませんか。
HogePtrという派生クラスを作ってポインタから暗黙的にキャストさせると
一番簡単にコンパイラを黙らせられるんですが、今度はコンテナを処理するときに
毎回HogePtrを作って比較するというコードを出してくるようになるので、
なるべく派生はさせずに済ませたい。
- 324 名前：デフォルトの名無しさん mailto:sage [05/02/16 20:11:57 ]
- 参照カウンタによるオーバーヘッドが許せないのなら、
shared_ptr系は精神衛生上使わないほうがいいと思う。
- 325 名前：デフォルトの名無しさん mailto:sage [05/02/17 00:41:46 ]
- >>323
bind の件は既に修正済みのはず。
- 326 名前：デフォルトの名無しさん mailto:sage [05/02/17 14:17:53 ]
- >>323
恐ろしいことだが君のようなハッカーには
それらはもうレガシーだ。boostなのにね。
sandboxにModern C++ Designのを移植した
policy_ptrというのがあるので見るべき
これはなかなか強烈だよ
- 327 名前：デフォルトの名無しさん mailto:sage [05/02/18 02:14:48 ]
- >>326
お前は独逸の詩人かよ!?
|
 |
