Boost総合スレ part7

1 名前：デフォルトの名無しさん [2009/01/19(月) 21:22:22 ] 過去スレ part 6 pc11.2ch.net/test/read.cgi/tech/1207749841/ part 5 pc11.2ch.net/test/read.cgi/tech/1192662575/ part 4 pc11.2ch.net/test/read.cgi/tech/1175663346/ part 3 pc11.2ch.net/test/read.cgi/tech/1158991211/ part 2 pc8.2ch.net/test/read.cgi/tech/1139313234/ part 1 pc8.2ch.net/test/read.cgi/tech/1091198276/ ■関連サイト■ Boost C++ Libraries www.boost.org/ Boost 翻訳プロジェクト boost.cppll.jp/HEAD/ Let's Boost www.kmonos.net/alang/boost/ boost info shinh.skr.jp/boost/ 357 名前：デフォルトの名無しさん [2009/04/19(日) 13:33:27 ] 確保される場所が違うだろ。 スタック上ではHDDにはうつりにくいけど 動的確保したらうつりやすい 358 名前：デフォルトの名無しさん mailto:sage [2009/04/19(日) 13:52:46 ] >355 vector から先頭アドレスをロード。 要素の内容をロード。 だから無意味だとは思わないが、なんで？ 毎回先頭アドレスをロードするのが無駄ってこと？ 359 名前：デフォルトの名無しさん mailto:sage [2009/04/19(日) 14:39:29 ] >>357 それは生配列かどうかとは違う問題では？ そもそも速度の変化を検知できるほど大きな配列をスタックに配置したら 数ページまるまる配列データだけになったりして、 そのページにアクセスする確率(≒スワップされない確率)は ヒープ領域と変わらなくなってしまうんじゃないか？ ていうかメモリ増やせ。 360 名前：デフォルトの名無しさん mailto:sage [2009/04/19(日) 17:51:13 ] うん、まぁほとんどの場合、生かvectorかで差がでることは メモリの再配列以外では無いのは確かなんだ。 でも1.5倍以上の差がでる可能性があるのも間違いないからね。 どちらにするか悩むのは無駄だが、知識として抑えておくのは 悪いことではないでしょう。 361 名前：デフォルトの名無しさん mailto:sage [2009/04/19(日) 18:39:44 ] >>358 生配列みたく movl (%edi,%ebx,4), %eax の1行でいいんじゃないの？ってことじゃないかと。 362 名前：デフォルトの名無しさん mailto:sage [2009/04/19(日) 18:41:40 ] >>361 まぁそうだとしたら >>355 は、レジスタの値とレジスタの値が指す先を混同してるってことか 363 名前：338 mailto:sage [2009/04/19(日) 22:55:36 ] ええと、皆様ありがとうございます。 アセンブラは全然理解出来ていないのですが、 頑張ってよく読ませていただきます。 364 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 00:21:29 ] >1.5倍以上の差がでる可能性があるのも間違いない どこからそんな結論が 365 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 00:57:25 ] >>360 まず、お前がもっと深い知識を蓄えてから発言しろ 366 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 06:23:45 ] 相手にも言えるレスで相手を馬鹿にしても、効果は薄いし説得力にも欠ける。 367 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 09:28:05 ] shared_ptrって参照数を保持する変数をnewしてるんだよね。てことは、 shared_ptr<int> pn(new int(0)); とか書くと、intはnewできてコンストラクタ内でnewが例外投げるとintのポインタが行方不明になる？ うん、なるな。 368 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 09:35:15 ] >>367 なんでドキュメントを読まずに「行方不明」とか意味のわからない結論で納得するの？ www.boost.org/libs/smart_ptr/shared_ptr.htm#constructors > Exception safety: If an exception is thrown, delete p is called. 369 名前：367 mailto:sage [2009/04/20(月) 09:46:13 ] うん、ヘッダ見たらすぐにわかった。恥ずかしい。 370 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 11:15:45 ] >>344 352も言ってるけど、何で生配列とboost::arrayで差が出るんだよ 353のループ部を gcc 4.3.3 -O2 で試したけど、まったく同じアセンブラコードになったぞ 371 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 11:38:09 ] お前の世界にはgccしかないのか？ 372 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 11:50:44 ] お前はgccよりひどい最適化のコンパイラを使うのか？ 373 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 11:51:38 ] multiarrayの方だけど ＞ boost::array<array_type::index,3> idx = {{0,0,0}}; ＞ A(idx) = 3.14; ＞この方法は次元非依存のコードを書くのに役立ち， ＞いくつかのコンパイラの下では operator[] よりも高いパフォーマンスをもたらす。 とboost.cppll.jpに解説があるくらいなので、オーバーライドされた[]が最適化 されないケースは間違いなくあるんだろう。 374 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 11:57:18 ] だな 375 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 12:02:56 ] つまり、boost::arrayで速度が問題になるようならより最適化されやすいA(idx)を使えばいいってこと? 376 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 13:43:59 ] 370の言ってることが間違いじゃなければgccなら最適化されるから 速度が問題になることはないだろう。 つまりgcc使えば良いんだよ。 ターゲット環境にgccが無いのなら、移植しろってことなんだろう。 377 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 21:04:20 ] >>375 multiarrayのoperator []が遅くなる要因は一時オブジェクトを作らないといけないからだと思う。 ところで、VC++ 9でも試してみたけど、やっぱりboost::arrayと生配列で出て来るコードは同じだった。 NDEBUGを定義して/O2で。 まあ普通のコンパイラならこれくらいGCCでなくても当然だと思う。 378 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 21:12:30 ] 最適化に関するたいした知識のない俺から見れば g++やVC++の最適化機能ってすんげーんだな と思う。 だって俺、最適化機能のあるコンパイラを作れって 言われても絶対無理だと思う。 そんな「boost::arrayと生配列で出て来るコードは同じ」みたいな ところまで気を回せるコンパイラの作者陣って ホントに尊敬するわ。 379 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 21:26:02 ] boost::arrayのコードを見れば ごく当たり前のことなんだけどな 380 名前：デフォルトの名無しさん mailto:sage [2009/04/20(月) 21:51:47 ] inline展開様々だな 381 名前：デフォルトの名無しさん mailto:sage [2009/04/21(火) 03:43:59 ] だな 382 名前：デフォルトの名無しさん mailto:sage [2009/04/21(火) 22:39:48 ] boost::shared_ptr<MyClass> ptr; これを関数に渡す場合、const参照渡しにした方が望ましいの？ それとも STLのイテレータや組み込み型変数のようにconst参照渡しよりコピー渡しの方が望ましいの？ 383 名前：デフォルトの名無しさん mailto:sage [2009/04/21(火) 23:01:47 ] 普通に値渡しの方がいいんじゃない？ どうせそこまで速度稼ぎたいわけじゃないだろうし、ポインタと同じように扱うためのスマートポインタだし。 384 名前：デフォルトの名無しさん mailto:sage [2009/04/21(火) 23:25:38 ] 値渡しじゃないと参照カウント増えないんじゃないか？ 385 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 00:19:58 ] >>384 関数内で、別の変数に代入するなどすれば、そのとき増えるので無問題。 それとは別の話で、もしptrの参照先を見るだけだったら、 ただのMyClass&/MyClass const&にすればいいな。 386 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 00:42:04 ] const参照にしとけ。 使ってる場所が多いと、値だと結構クルよ。 387 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 01:19:29 ] 呼び出し元次第。 const参照だと、実際に使うときに実体が存在しない危険がある。 388 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 06:13:57 ] >const参照だと、実際に使うときに実体が存在しない危険がある。 呼び出し元にはshared_ptrがあるのだから、関数実行中に実体が消えることはないと思うんだけど。 389 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 13:11:54 ] >>388 その理屈だとshared_ptr自体いらなくね？ 390 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 16:12:07 ] オブジェクトの寿命を自分で管理したいのか、shared_ptrに管理させたいのかで決めれば良いと思う 391 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 20:51:14 ] >>389 なんで？そんな理屈にはならんよ。 392 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 20:53:38 ] >>391 auto_ptrで充分じゃね？ 393 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 20:57:57 ] >>392 だからなんでそんなことになるの？ 394 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 21:01:08 ] >>392 auto_ptrは使用禁止でもおかしくない。 395 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 21:12:12 ] #define auto_ptr unique_ptr 396 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 21:37:41 ] >>392 おいおい素人にも程があるだろ・・・ 397 名前：382 mailto:sage [2009/04/22(水) 22:19:38 ] ふーむ、なるほどね。 そういったことを考えて決定するのが正しいのね。 ありがとう。 398 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 22:46:44 ] 引数は何も考えずconst参照にしといて問題ない 399 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 23:10:09 ] 組み込み型は値渡しがいいなあ 400 名前：デフォルトの名無しさん mailto:sage [2009/04/22(水) 23:43:04 ] >>398 組み込み型とイテレータは値渡しが望ましいとEffective C++で書かれていた気がするんだが。 401 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 00:11:10 ] 今はshared_ptrの話をしてるんじゃないのか 402 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 00:40:38 ] >388 それはshared_ptrのオーナー次第。関数自体はオーナーじゃ無いことに注意する必要がある。 下記はかなり恣意的な例だけど、マルチスレッドプログラムだとすぐ嵌りそうですな。 struct A { A() : s(new std::string) {}; boost::shared_ptr<string> s; } void doom(std::auto_ptr<A> body, boost::shared_ptr<string>& str) { *str; // boo!! }; int main() { std::auto_ptr<A> a(new A); doom(a, a->s); } 403 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 01:04:44 ] >>402 この例が一体何を示しているというのか。 boo!とか書いてるところで何か起きるわけでもなし。 404 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 01:26:28 ] >>402 それ問題ないです… マルチスレッドについてはconst参照でなく値渡ししたとしても、 コピー操作がアトミックじゃない以上は嵌る可能性があるよ。 shared_ptrの実装自体がconst参照使ってるわけだし、基本はconst参照でいいと思う。 405 名前：402 mailto:sage [2009/04/23(木) 02:11:38 ] 本当？>404 死んでるshared_ptrの参照剥しをしているんだけど？ まあ、マルチスレッドについてはアトミックなカウンタじゃないと死ぬっつうのは確かですな。 C++0xでマルチスレッド対応するらしいけど…… 406 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 02:14:31 ] >>405 お前、実行してみろ。本当？じゃねーよ。 407 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 02:19:37 ] >>405 doom() を抜けるまでは最初の new A で生成したインスタンスは生きてるように見えるが？ 408 名前：402 mailto:sage [2009/04/23(木) 02:53:07 ] あ、本当だ。ごめん。こうしないと死なないね。 まあ、マルチスレッドでもなきゃやらんだろうけど。 struct A { A() : s(new std::string) {}; boost::shared_ptr<string> s; } void doom(std::auto_ptr<A> body, boost::shared_ptr<string>& str) { { std::auto_ptr<A> b(body); } *str; // boo!! }; int main() { std::auto_ptr<A> a(new A); doom(a, a->s); } 409 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 02:59:58 ] >>408 なんかもう shared_ptr も何も関係ないな。 410 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 03:06:30 ] >>408 >>402がまずいコードなのは確かだけど、*strの問題じゃないよ。 bodyが先に生成されればa->sの時点で死ぬ。 strが先に生成されれば問題なし。 そして引数の評価順は不定であり、評価順依存のコードの実行結果は未定義なので、 コード自体が間違っている。 411 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 03:23:24 ] >>410 a による body の初期化って、順番が不定な「引数の評価」に含まれるの？ 5.2.2 Function call の p4 より > When a function is called, each parameter shall be initialized with its corresponding argument. 同じく p8 より > All side effects of argument expression evaluations take effect before the function is entered. とか、読んでみたけどはっきりしない。 412 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 07:40:17 ] まあとにかく、shared_ptrは何も考えずconst参照にしといて問題ないよ。 413 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 12:36:08 ] >>411 5.2.2 p4のこれがそうなんじゃないかなあ。 >The initialization and destruction of each parameter occurs within the context of the calling function. 414 名前：382 mailto:sage [2009/04/23(木) 19:20:17 ] ふーむ。 試しに void foo(const boost::shared_ptr<MyClass> &p) { p->m_func(); } と void foo(boost::shared_ptr<MyClass> p) { p->m_func(); } とだけが異なった2種のソースをg++に渡して-O2でコンパイルさせてみたら、 後者の方が大きかったんだが。 とりあえずこのソースに限り、ファイルサイズはconst参照じゃない方が小さく済むみたい。 実行時間は・・・どうやって調べればいいの？ 415 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 20:17:17 ] ？ 416 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 20:29:06 ] >>414 とりあえずcodepadかどこかにソースうｐしてもらえないとなんとも 417 名前：414 mailto:sage [2009/04/23(木) 20:41:45 ] さすがにエスパー要求しすぎなレスだったね。 すまなかった C++ code - 38 lines - codepad ttp://codepad.org/xAdtSWJO コピーバージョン。 C++ code - 38 lines - codepad ttp://codepad.org/nNuvdFvf const参照バージョン このソースをg++に渡してコンパイラオプション-O2で コンパイルさせてみたら、後者の方が大きかった。 となると、後者の方が効率が悪いってことかなぁ →でも効率を論ずるならやっぱり速度を測定しないとなぁ →速度の実測ってどうすればいいのか分からない ってことです。m(_ _)m 418 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 21:45:07 ] それくらい自分で調べろ、っていうか速度気にするレベルじゃなくない？ 419 名前：414 mailto:sage [2009/04/23(木) 23:18:17 ] >>418 それもそうだな。 boostのtimerでも使うか。 420 名前：デフォルトの名無しさん mailto:sage [2009/04/23(木) 23:28:56 ] const参照は不完全型が許されるのがいい。 421 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 10:10:05 ] デフォでconst参照でいいってぐらいconst T&ばっかりになるから困る 422 名前：414 mailto:sage [2009/04/24(金) 14:56:00 ] 報告： 結局const参照verの方が遅かった。 サンプルソースでだけど。 423 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 15:30:22 ] const& で遅くなることなんてあるんだ 424 名前：414 mailto:sage [2009/04/24(金) 15:53:05 ] >>423 C++ code - 45 lines - codepad ttp://codepad.org/NiHfAcx4 これの void the_function(boost::shared_ptr<MyClass> p) を void the_function(const boost::shared_ptr<MyClass> &p) にしてみたバージョンとで比較してみて。 俺はconst参照verの方が遅くなったよ。 425 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 16:27:09 ] $cat foo.cxx #include <iostream> #include <boost/progress.hpp> #include <boost/shared_ptr.hpp> class MyClass { public: 　　virtual void f(){std::cerr << "MyClass f!" << std::endl;}; 　　MyClass(){std::cerr << "MyClass Constructor!" << std::endl;}; 　　virtual ~MyClass(){std::cerr << "MyClass Destructor!" << std::endl;}; }; void the_function(boost::shared_ptr<MyClass> p){ p->f(); } void the_function_cr(boost::shared_ptr<MyClass> const& p){ p->f(); } int main(){ 　　const int M=0xffff, N=0xf; #define FOO(f) {　　　　　　　　　　　　　　　　　　　　\ 　　　　boost::progress_timer t;　　　　　　　　　　　　\ 　　　　boost::shared_ptr<MyClass> po(new MyClass);　　 \ 　　　　for( unsigned long i=0; i<M; ++i )　　　　　　　\ 　　　　　　for( unsigned long j=0; j<N; ++j )　　　　　\ 　　　　　　　　(f)(po);　　　　　　　　　　　　　　　　\ 　　} 　　FOO(the_function); 　　FOO(the_function_cr); } $g++ foo.cxx $./a.out 2>/dev/null 0.85 s 0.81 s 誤差じゃね？ 426 名前：414 mailto:sage [2009/04/24(金) 16:37:53 ] >>425 おや、俺の環境と逆転した結果か？ うーん、どうなんだろう？ 427 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 18:01:08 ] >>425 iostreamが重そうだと思ったから、 ダミーの関数呼出(GetCurrentProcess)にしてやってみた。 ただし、N = 0xfffに変更。共に-O2使用。 Cygwin g++ 3.4.4 5.87 s 1.79 s VC++ 2008 SP1 7.70 s 1.12 s やっぱり参照カウンタの操作が重いんだと思う。 ちなみに、BOOST_SP_DISABLE_THREADS（参照カウンタの操作にアトミックなやつを使わない） を指定すると、値渡し版の所要時間が4割くらい減る。 428 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 18:25:28 ] 値渡しのほうが遅くなるのなら納得 429 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 19:51:49 ] 参照よりもコピーコンストラクタが走るほうが速いというのは なんだかおかしな気がするわな 430 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 22:24:06 ] >>414と>>417で言ってることが逆なのはどういうことなんだ？ 手元ではコピーコンストラクタのほうが実行コードが大きくなったぞ？ 431 名前：414 mailto:sage [2009/04/24(金) 22:30:17 ] 俺は二種類のサンプルソースで試したけど参照渡しの方が大きかった。 ・・・もしかして参照渡しになっているところの数によって変化する要因があるとか？ あとは最適化か？？ 432 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 22:34:34 ] >>431 一時オブジェクトが作られてないか？ 433 名前：414 mailto:sage [2009/04/24(金) 22:42:48 ] >>432 ちゃんとconst参照渡しだから大丈夫なはずなんだが。。。 う〜ん？ まあ速度は・・・誤差かもしれない。 相当回数トライして結果をt検定してみないと有意に早いとは証明できない程度。 でもサイズは誤差じゃなくcopy_verの方が小さいです。 434 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 22:45:23 ] >>431 つまり、>>414は間違いだったってことでいいの？ 435 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 22:48:23 ] 更新しました。ここ暫くはGraphの更新が多いです。それから、Cmakeでのビルド環境が整備されつつある様です。 ttp://booster.x0.to/ 以下更新内容の一部 [Graph] Applied performance patch from Jongsoo Park. Importing null (no-op) property map from SOC/2007. [Math] Add some macro-expansion-suppression code to test_sign.cpp. Fix for no long double math functions. [Smart_ptr] Bring back "explicit" on the auto_ptr rvalue constructor. Refs #2951. 436 名前：414 mailto:sage [2009/04/24(金) 22:49:09 ] >>434 いや、const参照渡し版よりcopy版の方がこちらの環境ではわずかながら早い。 ただそれが有意な差であると言い切れるかは検定してない。 あと、コンパイラのバージョンがg++ 3.4.5(MinGW)であることを追記し忘れたm(_ _)m >とりあえずこのソースに限り、ファイルサイズはconst参照じゃない方が小さく済むみたい これは確か。 437 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 22:49:25 ] [Asio] Don't include termios.h unless BOOST_ASIO_HAS_SERIAL_PORT is defined. [Property_map] Approximated non-ASCII character by ASCII one [Pending] Fixed tab [Signals2] Fix c++0x perfect forwarding for deconstruct. [Functional] Fix float support on vxWorks. [Connfig] Added support for vxworks.hpp. Fixes #2959. [Fsion] Trying to fix ambiguities of operator<<() for unused_type. [Regex] Added possessive modifiers ++ *+ ?+ {}+. Added support for \v and \h as character classes as per Perl-5.10. [Serialization] Add missing 'inline'. Don't include <exception> when excepetions are disabled. 438 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 22:53:49 ] >>436 いや、だからさあ、 >>414と>>417であなたが言ってることは逆でしょう？ どこかでファイルを取り違えていたりしない？ 439 名前：414 mailto:sage [2009/04/24(金) 22:57:07 ] >>438 ごめん 既に>>414の段階でおかしかった。 吊ってくる。 >つまり、>>414は間違いだったってことでいいの？ おっしゃるとおり逆だ。 >とりあえずこのソースに限り、ファイルサイズはconst参照じゃない方が小さく済むみたい これは正しい。 そして>>435様に挟む形でレスして申し訳ございません。 440 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 22:59:44 ] >>414 gccのバージョンと環境を教えて。 441 名前：414 mailto:sage [2009/04/24(金) 23:01:51 ] >>440 Windows XP Home Edition SP2 C:\>g++ --version g++ (GCC) 3.4.5 (mingw special) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. BoostはRelease 1.37.0 442 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 23:05:51 ] またずいぶんと古いバージョン使ってるなぁ。 うちの会社は未だに2.9系使ってるけど。 443 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 23:07:49 ] >>442 MinGWが未だ3.4.5しか対応してくれていないんだ。 正式版じゃなければ4.x.x系列のもあるらしいんだが。。。 444 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 23:20:21 ] まあまあ、Cygwinだって基本は3.4.4ですよ。別途g++-4とかが入れられるけど。 445 名前：443 mailto:sage [2009/04/24(金) 23:27:12 ] >>444 ああ、やっぱそうなのか。 じゃあ不満持ってもしかたないか。 446 名前：デフォルトの名無しさん mailto:sage [2009/04/24(金) 23:55:50 ] MinGWでいつもGCC4.xを自分でビルドして使ってる 447 名前：デフォルトの名無しさん mailto:sage [2009/04/25(土) 13:59:35 ] mingwはlibiconvをインクルードしなくなったのと 3.4.5でwstringが未対応なので、野良の4.3.3使ってる。 まあ普通に動くよ。Dwarf2でVC近い速度が出るし。 448 名前：デフォルトの名無しさん mailto:sage [2009/04/26(日) 03:00:54 ] Windows 7 64bit でboost群使える？ 色々テストしてみたいんだけど 449 名前：デフォルトの名無しさん mailto:sage [2009/04/26(日) 03:36:54 ] コンパイラさえ動けば問題ないだろ。 450 名前：デフォルトの名無しさん mailto:sage [2009/04/27(月) 16:43:09 ] 今までhoge.cppファイルの中でboost::bindを使っていたのだけれど、 今度そのhoge.cppにboost::lambdaも使うことにしようと思っている。 なお、このhoge.cpp以外でboost::bindおよびboost::lambdaは使用していない。 このような時は 1.boost::lambdaをただ追加する （＝<boost/bind.hpp>と<boost/lambda/lambda.hpp>をインクルードする。） 2.boost::bindを使っている箇所も全てboost::lambdaに置き換える （＝<boost/lambda/lambda.hpp>だけインクルードする。） このどちらが良いのかい？ 451 名前：デフォルトの名無しさん mailto:sage [2009/04/27(月) 16:59:24 ] boost::bindはグローバルに_1とか置く割と行儀が悪いライブラリだったりするんで俺なら2を選ぶ 452 名前：450 mailto:sage [2009/04/27(月) 17:05:52 ] >>451 > boost::bindはグローバルに_1とか置く割と行儀が悪いライブラリだったりするんで俺なら2を選ぶ そうだったんか。 そういえばboost:lambdaの_1とかとバッティングすることがあると聞いた気がするなぁ。 まあbindは古株だからかな？ 453 名前：デフォルトの名無しさん mailto:sage [2009/04/27(月) 17:46:19 ] bindのところをlambdaにしたらそれだけでファイルサイズが60kbくらいあがったわ。 ・・・でもPC向けだしこのくらいいいかな、利便性を考えれば。 454 名前：デフォルトの名無しさん [2009/04/27(月) 23:09:28 ] 初心者ですがお願いします.以下のようなエラーが出て困っています。 boostのbind.hでerror C2825: 'F': '::' が後に続くときは、クラスまたは名前空間でなければなりません c:\includefiles\boost\bind.hppと出ます。 いかがその部分です template<class F> struct result_traits<unspecified, F> { typedef typename F::result_type type; }; 色々サイトで調べてみたのですが、#include <boost/bind.h>の前に #define BOOST_BIND_ENABLE_STDCALL #define BOOST_MEM_FN_ENABLE_STDCALLを書くと良いと記載されていたのですが、 エラーが取れません。原因がわかりませんでしょうか？ 455 名前：デフォルトの名無しさん mailto:sage [2009/04/27(月) 23:27:35 ] >>454 result_traitsの後に<は書けなくね？ 456 名前：デフォルトの名無しさん [2009/04/27(月) 23:50:15 ] >>455さん ご返事ありがとうございます。 エラーの箇所を確認したのですが、bind.hの中からエラーを出力しているようです。 boostの中のバグということでしょうか？ 457 名前：デフォルトの名無しさん mailto:sage [2009/04/28(火) 00:10:18 ] >>456 エラーの発生する自分で書いた側のコードをupして。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef