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/
642 名前:デフォルトの名無しさん mailto:sage [2009/06/09(火) 20:16:10 ] spiritの方が大抵速いようだしな。 それでいて柔軟性もあるし
643 名前:デフォルトの名無しさん mailto:sage [2009/06/09(火) 20:34:08 ] spiritとか使ったことがないが、コンパイルにやたらと時間がかかりそうで怖いんだが。
644 名前:デフォルトの名無しさん mailto:sage [2009/06/09(火) 20:38:28 ] コンパイルに時間が掛かるのはその通りだが、今時大した問題でも無いと思う。 まずは使ってみて便利さとコンパイル時間を天秤にかければ良いだろうな。
645 名前:デフォルトの名無しさん mailto:sage [2009/06/09(火) 21:33:44 ] コンパイルするのにメモリもかなり食う まぁ一度コンパイルしてしまえば(文法規則が変わらない限り)関係ない話だし
646 名前:デフォルトの名無しさん mailto:sage [2009/06/09(火) 21:36:27 ] >>640 >>643 Boost.Spiritは、ぜひとも一度使ってみて、 Boost.Lambdaと同様のあまりの変態さにおののいてみてください。 すげーよまじで。
647 名前:デフォルトの名無しさん mailto:sage [2009/06/10(水) 01:21:08 ] yacc と比較して spirit の構文解析の速度はどうですか? spirit で何度か C 風文法を解析するプログラムを作ったのですが パース時に後戻りが多いような気がするのですが。
648 名前:デフォルトの名無しさん mailto:sage [2009/06/10(水) 03:36:23 ] >>647 実際に同じ文法を定義してベンチマーク取ったわけではないけど、spiritは 再帰下降パーサだからバックトラックが遅いんだろうな。 効率が気になる程に長いファイルをパースするなら、やっぱりLALRパーサの bison(yacc)を使った方が良いと思う。
649 名前:デフォルトの名無しさん mailto:sage [2009/06/10(水) 09:00:32 ] v2の方はコンパイルでアホのようにメモリ喰うな ちょっとした文法でも1GB普通に超える
650 名前:デフォルトの名無しさん mailto:sage [2009/06/12(金) 19:34:55 ] 更新しました。bjamでのビルドに於いて、"--build_all"オプションが削除されました。 ttp://booster.x0.to/ 以下更新内容の一部 [Graph] Reverted old version of CSR graph for compatibility, with a #define to switch between the modes; cleaned up interface of new CSR graph; fixed tests and docs accordingly Changed to shared_array_property_map Sped up out_degree() and related functions for new interface [Python] Allow duplicate enum values. Fixes #2744 [Example] examples of external main usage typo [Regex] Simplify and fix PP logic. [Impl,Exeption,Mpl,Detail,Smart_ptr] avoid C style casts [Numeric] Fix a couple of typos in the ublas documentation. Fixes #3056, #3057. [Variant] Support BOOST_NO_TYPEID and BOOST_NO_IOSTREAM in Boost.Variant. Fixes #3051. [Spirit] Spirit: added placeholders for lexer semantic actions Spirit: Lot of work done in Lexer, fixed bugs, added support functions, refactored code [Proto] virtual_members get proto_arity_c [Serialization] Update include from boost/pfto.hpp to boost/serialization/pfto.hpp. Refs #3062. [Signals2] Added a copy of Thorsten Ottosen's auto_buffer into signals2/detail and used it to replace stack_allocator/stack_vector (which worked on popular compilers but were not strictly standards conforming).
651 名前:デフォルトの名無しさん [2009/06/12(金) 20:02:43 ] foreach ( int a, boost::assign::list_of ( 1 ) ( 2 ) ( 3 ) ) { ... } でコンパイルエラーが出るんだが、こういうのは無理? e:\boost\boost\assign\list_of.hpp(163) : error C2661: 'boost::foreach_detail_::rvalue_probe<T>::rvalue_probe' : 2 個の引数を伴うオーバーロードされた関数はありません。
652 名前:デフォルトの名無しさん [2009/06/12(金) 21:05:22 ] boost::flyweight<std::string, boost::flyweights::set_factory<std::less<boost::mpl::_2> > > fw1("1"); std::cout << &fw1.get() << "\n"; boost::flyweight<std::string, boost::flyweights::set_factory<std::less<std::string> > > fw2("1"); std::cout << &fw2.get() << "\n" 以下の4つソースは全て同じ結果になることを期待していたのですが、同じ結果になりません。 (1) boost::flyweight<std::string> fw1("1"); std::cout << &fw1.get() << "\n"; (2) boost::flyweight<std::string, boost::flyweights::hashed_factory<> > fw2("1"); std::cout << &fw2.get() << "\n"; (3) boost::flyweight<std::string, boost::flyweights::hashed_factory<boost::hash<boost::mpl::_2>, std::equal_to<boost::mpl::_2> > > fw3("1"); std::cout << &fw3.get() << "\n"; (4) boost::flyweight<std::string, boost::flyweights::hashed_factory<boost::hash<std::string>, std::equal_to<std::string> > > fw4("1"); std::cout << &fw4.get() << "\n"; (1)と(2)は同じ結果になりますが、(3)と(4)が(1)や(2)と同じ結果にならないのは、どうしてでしょうか? (1)と(2)に関してここにも書いてるので、当然な結果・・・ www.boost.org/doc/libs/1_38_0/libs/flyweight/doc/tutorial/configuration.html#hashed_factory
653 名前:652 [2009/06/12(金) 21:06:41 ] 余計なソースまで貼ってしまったので、再度投稿します。 以下の4つソースは全て同じ結果になることを期待していたのですが、同じ結果になりません。 (1) boost::flyweight<std::string> fw1("1"); std::cout << &fw1.get() << "\n"; (2) boost::flyweight<std::string, boost::flyweights::hashed_factory<> > fw2("1"); std::cout << &fw2.get() << "\n"; (3) boost::flyweight<std::string, boost::flyweights::hashed_factory<boost::hash<boost::mpl::_2>, std::equal_to<boost::mpl::_2> > > fw3("1"); std::cout << &fw3.get() << "\n"; (4) boost::flyweight<std::string, boost::flyweights::hashed_factory<boost::hash<std::string>, std::equal_to<std::string> > > fw4("1"); std::cout << &fw4.get() << "\n"; (1)と(2)は同じ結果になりますが、(3)と(4)が(1)や(2)と同じ結果にならないのは、どうしてでしょうか? (1)と(2)に関してここにも書いてるので、当然な結果・・・ www.boost.org/doc/libs/1_38_0/libs/flyweight/doc/tutorial/configuration.html#hashed_factory
654 名前:デフォルトの名無しさん mailto:sage [2009/06/14(日) 13:13:18 ] boost::typeクラステンプレートって何に使うの? 適当な引数として boost::type<t>* = 0 のように使っているようだが、意図がよく分からん。
655 名前:デフォルトの名無しさん mailto:sage [2009/06/14(日) 15:17:09 ] >>654 C++は関数テンプレートの部分的特殊化ができないが、オーバーロードを使って同じような事ができる。 boost::type<Hoge>とかboost::type<Fuga>とか引数を変えてオーバーロードし、 Function(x, boost::type<Hoge>());みたいな感じで呼び出す。 boost::type<Hoge>はコンパイラの最適化で消えるため、実行時のコスト0で実現できる。
656 名前:654 mailto:sage [2009/06/14(日) 16:06:02 ] >>655 ふーむ。。。 template <typename TIPE> void Function(int x){〜}; とでも定義しておいて Function<TYPE>(x); と呼び出すんじゃだめなのかい?
657 名前:デフォルトの名無しさん mailto:sage [2009/06/14(日) 18:02:25 ] >>656 >>655 はこういうことだと思う template<class T> void f(T, ...) { std::cout << "T"; } template<class T> void f(T*, boost::type<T>) { std::cout << "T*"; } int main() { double d = 0; int i = 0; f(d); f(&i, boost::type<int>()); f(&d, boost::type<double>()); }
658 名前:656 mailto:sage [2009/06/14(日) 21:10:20 ] >>657 悩んだ末、何となく意味が分かった気がする。 部分特殊化で template<class TYPE *> void f<TYPE *>(TYPE *, ...) としたくても出来ないから、 普通の型用とポインタ型用の2つを多重定義するオーバーロードで 似たようなことをしている訳か。 二人ともありがとう!
659 名前:655 mailto:sage [2009/06/14(日) 22:31:03 ] >>656-658 言いたかったのは、 Modern C++ Design 30ページより > ・クラス・テンプレートのメンバ関数については完全な特殊化ができるものの、メンバ関数の部分的な特殊化はできません。 > ・ネームスペース・レベルにおける関数(非メンバ関数)の部分的な特殊化はできません。 > ネームスペースレベルにおけるテンプレート関数に対して許されている機能のうち、部分的な特殊化に最も近いものはオーバーロードです。 > つまり実用上は、関数パラメータに対してのみ(戻り値や内部的に使用される型は適用できません)細かい粒度の特殊化能力を与えることができるわけです。例えば: > template <class T, class U> T Fun(U obj);// 一次テンプレート > template <class U> void Fun<void, U>(U obj);// 部分的な特殊化(不正) > template <class T> T Fun(Windows obj);// オーバーロード(正当) そして template <class T> void Function(T x, Hoge/*ダミー*/); ではなく template <class T> void Function(T x, boost::type<Hoge>/*ダミー*/); とすることによって実行速度に影響を与えずオーバーロードを解決できる(boost::type<T>のサイズが0のため)。
660 名前:655 mailto:sage [2009/06/14(日) 22:33:31 ] オーバーロードというのは template <class T> void Function(T x, boost::type<Hoge>/*ダミー*/); template <class T> void Function(T x, boost::type<Fuga>/*ダミー*/); っていうこと。
661 名前:658 mailto:sage [2009/06/15(月) 07:05:57 ] >>659 ふーん、なるほど。 Boostでやたら多用されているのも分かる気がしてきた。
662 名前:デフォルトの名無しさん mailto:sage [2009/06/15(月) 21:47:30 ] 素朴な疑問です。 shared_ptrやscoped_ptrには下記のオペレータがあります。 T& operator*() const; T* operator->() const; 実装から考えれば全くその通りだと思います。 でも生ポインタを抽象化するという役割を考えると、 下記の方が理にかなっているように思えてなりません。 const T& operator*() const; const T* operator->() const; T& operator*(); T* operator->(); 後者がNGで、前者でなければならない理由とかがあるのでしょうか?
663 名前:デフォルトの名無しさん mailto:sage [2009/06/15(月) 21:50:02 ] T const* と T* const の違いを考えてみればいい。
664 名前:デフォルトの名無しさん mailto:sage [2009/06/15(月) 22:15:29 ] >>663 なるほど! 確かにポインタ自身のconstを考えると納得です。 すっきりしました。 ありがとうございました。
665 名前:デフォルトの名無しさん mailto:sage [2009/06/16(火) 15:07:43 ] 継続はいつ実装されるんだ
666 名前:デフォルトの名無しさん mailto:sage [2009/06/20(土) 22:21:29 ] 更新しました。 ttp://booster.x0.to/ 以下更新内容の一部 [Graph] Changed function types to enums and removed include of iostream; refs #3134 Added constructors from multi-pass unsorted, filtered edge lists; refs #3134 Added extra named parameters for McGregor maximal common subgraph algorithm; contributed by Michael Hansen; refs #3134 [Functional] Try to avoid float to int warning when a float function doesn't exist. Refs #3171. [Spirit] Spirit: Added operator safe_bool to lexer token type Spirit: Simplified multi_pass iterator Spirit: Fixing bogus assertions Fixup to add() again for Hartmut. Spirit: Made dummy token constructor explicit [Random] Supress warnings from narrowing conversions. [Fusion] introduces unfused adapter fix trac issue #1608 [Proto] accomodate fusion:vector0 interface change [Graph_parallel] Fixed bugs in test case; refs #3134 Fixed warnings; refs #3134 [Python] Use appropriate default values for global and local dicts. [Impl] Fixed support for CRT hooks, it was not working properly with catch_system_errors=no
667 名前:デフォルトの名無しさん mailto:sage [2009/06/20(土) 22:38:49 ] これは乙じゃなくてなんたらかんたら
668 名前:デフォルトの名無しさん mailto:sage [2009/06/27(土) 05:07:54 ] program optionsライブラリって機能の割にはコンパイルしてlib用意しなきゃダメなんだね OSに依存することやってるわけでもなさそうなのに何故なんだぜ?
669 名前:デフォルトの名無しさん mailto:sage [2009/06/27(土) 10:26:24 ] コンパイラに依存することやってたと思った
670 名前:デフォルトの名無しさん mailto:sage [2009/06/27(土) 19:08:43 ] >>668 テンプレートやインライン関数でないものを含んでいるんじゃないの
671 名前:デフォルトの名無しさん mailto:sage [2009/06/27(土) 20:44:52 ] program_optionsのファイル読み込みはいらないよなぁ シリアライズの方が手っ取り早いし、ちゃんとやるならspirit使うし
672 名前:デフォルトの名無しさん mailto:sage [2009/06/27(土) 21:53:00 ] program_optionsはBoostに含まれるにしては割と 出来が良くない気がする。 まあライセンスが緩いBoostだから、いっぱいあるのは俺は歓迎だけどさ。
673 名前:progress_display mailto:sage [2009/06/27(土) 22:16:05 ] 俺もそう思う
674 名前:program_options mailto:sage [2009/06/27(土) 22:36:10 ] >>673 お前にだけは言われたくない
675 名前:672 mailto:sage [2009/06/27(土) 22:38:28 ] >>674 まあまあ。 喧嘩うるなよ。
676 名前: ◆/91kCCQXBo mailto:sage [2009/06/28(日) 01:39:40 ] >>113 ソートのアルゴリズムは習ってないということで。 #include <stdio.h> #include <stdlib.h> struct seiseki { char name[20]; int order[6]; } seito[] = {{"太郎",80,90,75,70,70}, {"次郎",70,85,80,80,85}, {"三郎",75,95,65,90,95}, {"四郎",65,70,80,75,80}, {"春子",90,100,85,90,85},{"夏子",100,95,80,85,80}, {"秋子",60,75,90,70,85}, {"冬子",85,80,85,90,95}}; int kamoku; int cmp(const struct seiseki *a, const struct seiseki *b) { int t = a->order[kamoku] - b->order[kamoku]; return (t==0)?0:(t>0?1:-1); } int main() { int i, array_size = sizeof(seito)/sizeof(*seito); char s_kamoku[6][10] = {"国語","算数","理科","社会","英語","合計"}; for(i=0; i<array_size; i++) { seito[i].order[5] = seito[i].order[0] + seito[i].order[1] + seito[i].order[2] + seito[i].order[3] + seito[i].order[4]; printf("%s,%3d,%3d,%3d,%3d,%3d,%4d\n", seito[i].name, seito[i].order[0], seito[i].order[1], seito[i].order[2], seito[i].order[3], seito[i].order[4], seito[i].order[5]); } for(kamoku=5; kamoku>=0; kamoku--) { printf("\n%sの点数で並び替え\n", s_kamoku[kamoku]); qsort(seito, array_size, sizeof(*seito), (int (*)(const void*, const void*))cmp ); for(i=0; i<array_size; i++) { printf("%s,%3d,%3d,%3d,%3d,%3d,%4d\n", seito[i].name, seito[i].order[0], seito[i].order[1], seito[i].order[2], seito[i].order[3], seito[i].order[4], seito[i].order[5]); } } return 0; }
677 名前:デフォルトの名無しさん mailto:sage [2009/06/28(日) 01:42:34 ] 宿題スレの誤爆?
678 名前:shared_ptr mailto:sage [2009/06/28(日) 08:25:16 ] includeするだけで使えるってのがウリの一部だというのに・・ 本当使えないなモマイラは
679 名前:mpl mailto:sage [2009/06/28(日) 11:56:22 ] >>678 あんなクソでかいライブラリをコンパイルするのなんて待ってられないよなw
680 名前:spirit mailto:sage [2009/06/28(日) 15:46:58 ] 同意
681 名前:デフォルトの名無しさん mailto:sage [2009/06/28(日) 16:10:57 ] おまいらおもろいなw
682 名前:noncopyable mailto:sage [2009/06/28(日) 17:27:03 ] >>678 >>679 >>680 おまえら、俺様の前に跪けよな。
683 名前:xpressive mailto:sage [2009/06/28(日) 20:32:19 ] regexはいらない子
684 名前:デフォルトの名無しさん mailto:sage [2009/06/28(日) 20:38:01 ] regexの方がコンパイル速度速いだろ?
685 名前:デフォルトの名無しさん mailto:sage [2009/06/28(日) 20:41:15 ] >>684 俺は 「Boost.Regexは動的正規表現だから、 ユーザーに正規表現文字列を入力してもらって 動的な検索を提供できるのでは」 と思っているのだが。 そんな機会が無くて試したこと無いけど。 Boost.Xpressiveもいる子
686 名前:デフォルトの名無しさん mailto:sage [2009/06/28(日) 20:51:01 ] xpressiveにも動的正規表現処理はあるんだよ。
687 名前:デフォルトの名無しさん mailto:sage [2009/06/28(日) 20:54:31 ] >>686 マジか! じゃあもうBoost.Regexは… …いや、なんでもない。
688 名前:デフォルトの名無しさん mailto:sage [2009/06/28(日) 21:04:41 ] 残念ながらC++0xに採用されるのはboost::regexなのだよ。
689 名前:parameter mailto:sage [2009/06/28(日) 21:17:07 ] お前らあまりprogram_optionsいじめるなよ
690 名前:boost::tuple mailto:sage [2009/06/28(日) 21:28:29 ] tr1にも入ってるし、僕はいる子ですよね!
691 名前:687 mailto:sage [2009/06/28(日) 21:29:53 ] tr1に入るのがBoost.Regexなのは、 歴史的な理由? つまりある程度枯れているから信頼性があるとか?