07/01/06 09:17:55
shared_ptrやweak_ptrのソースを調べてるんだけど、
shared_ptrは内部でweak_ptrを使ってるようだけど、これは何のため
なんだろうか。weak_ptrはshared_ptrの循環参照の欠点を克服できる
という話を聞いてるんだけど、shared_ptrのなかにすでにweak_ptrが使われてる
ということは、もうshared_ptrは循環参照を克服したってことでいいんですか？
違うとしたら、weak_ptrをどう使ってshared_ptrの循環参照を克服できるのか
教えてください。weak_ptrのソースみてみると、なんだかweak_countという
別のカウンタを使っているだけで中身はほとんどshared_ptrと同じように参照カウンタ方式
にみえるんだけど、これで本当に循環参照、解決するんだろうか…？
549:デフォルトの名無しさん
07/01/06 10:05:47
URLﾘﾝｸ(www.kmonos.net)
ここのスマートポインタってところ読んでから来いや。
550:デフォルトの名無しさん
07/01/06 10:12:40
>もうshared_ptrは循環参照を克服したってことでいいんですか？
よくない。
weak_countは参照カウンタの参照カウンタとでも言えばいいんだろうか。
struct A { shared_ptr<A> a; }
shared_ptr<A> hoge(new A);
hoge.a = hoge;
struct A { weak_ptr<A> a; }
shared_ptr<A> hoge(new A);
hoge.a = hoge;
この二つでどのように参照カウンタが変化するのか、調べてみるといいよ。
551:デフォルトの名無しさん
07/01/06 11:16:45
>550
shared_ptrはカウンタ増えるけど、
weak_ptrはカウンタ増えないね。weak_ptrのカウンタはなぜ増えない？？
代入で増えるように定義されてるように見えたんだけど
>549
いちおう読みました
552:デフォルトの名無しさん
07/01/06 13:50:29
循環参照が置きるshared_ptrの相互参照がある場合、
相互参照の片方をweak_ptrに置き換えて循環参照が解決できる、
という理解でよろしいんでしょうか、ご教授ください
553:デフォルトの名無しさん
07/01/06 13:51:53
そんな事、人に訊かんとわかんないもんかね。
554:デフォルトの名無しさん
07/01/06 14:34:16
>553
これって実は誰でも知ってること？？
555:デフォルトの名無しさん
07/01/06 14:36:23
＞相互参照の片方をweak_ptrに置き換えて循環参照が解決できる
この説明だと片方を単にポインタに置き換えるだけで良いじゃないか，という反論が
想定され， weak_ptr の本質的な利点と特徴を説明できていないような？
556:デフォルトの名無しさん
07/01/06 15:22:57
>>554
皆知ってるかは知らんが、自分で結論出せないのなら
完全に理解できてないってことだ。
557:デフォルトの名無しさん
07/01/06 15:45:06
そりゃ完全に理解できてないから訊いてるんだろ。
558:デフォルトの名無しさん
07/01/06 15:48:06
>555
単にポインタに置き換えるだけだと、自動で消えないからマズいんですよね？？
weak_ptrなら、相互参照の片方が消えたら自分も消えるんでウマいこと
いくってことでＯＫ？
>556
結論を出してみたけど間違ってたまま覚えてたらまずいんで
合ってるのかどうかだけでも教えてください
559:デフォルトの名無しさん
07/01/07 03:14:24
boostのUnitTestってCppUnitと比べてどんな感じですか？
560:デフォルトの名無しさん
07/01/07 03:26:17
マグロとイカフライみたいな感じかな
561:デフォルトの名無しさん
07/01/07 03:32:22
>>560 ありがとうございました
562:デフォルトの名無しさん
07/01/07 05:51:31
ちょｗｗ
563:デフォルトの名無しさん
07/01/07 13:58:09
weak_ptrにいれたshared_ptrのカウントと、weak_ptrのカウントが
同じカウントになるような気がする。
つまりshared_ptrが消えるときにweak_ptrのカウントもゼロになって
同時に消える仕掛けになってると考えていいんでしょうか先生？
564:デフォルトの名無しさん
07/01/07 15:19:12
ちがった・・・入ってるshared_ptrが消えてもweak_ptrのカウントは１残った…
それまではカウント同じなのになぜ？？
565:デフォルトの名無しさん
07/01/07 20:29:47
>>558
＞単にポインタに置き換えるだけだと、自動で消えないからマズいんですよね？？
いや， weak_ptr の機能は参照先のオブジェクトの生存管理と直接は無関係です．
普通のポインタで参照していようが， weak_ptr で参照していようが，
shared_ptr による参照カウントが0になればそのオブジェクトは消えます．
単なるポインタと比較した場合の weak_ptr の利点は，
-参照先のオブジェクトが生存しているかどうかを調べることができて，かつ
-shared_ptr に格上げできる
ことです．
いずれにせよ， shared_ptr による循環参照の問題の解決するにあたって，
必ず weak_ptr の機能が必要になるわけではないです．
単に weak_ptr の機能を理解しようとするだけなら，
循環参照の問題はとりあえず脇に置いておいた方が良いような気がします．
566:デフォルトの名無しさん
07/01/07 20:46:53
>>563
shared_ptr の実装は，参照カウントによって管理されるオブジェクト
(A とします) と独立して，新たにフリーストア (ヒープ) 上に
参照カウント用のオブジェクト (X とします) を生成します．
X は， A の参照カウントと独立して自分自身の参照カウントも持っていて，
独立した2つの参照カウントを持っているイメージになります．
shared_ptr が1つ作られるごとに A の参照カウントと X の参照カウント両方が
1つ増やされ， shared_ptr が1つ破壊されるごとに
A の参照カウントと X の参照カウント両方が1つ減らされます．
weak_ptr が1つ作られるごとに X の参照カウントのみが増やされ，
weak_ptr が1つ破壊されるごとに X の参照カウントのみが減らされます．
A の参照カウントが0になれば A を delete します．
しかし， X の参照カウントが0になっていなければ X は破壊されません．
最終的に全ての shared_ptr と weak_ptr が存在しなくなった時点で，
X の参照カウントは0になります．この時点で X は delete されます (自殺します)．
以上が， shared_ptr と weak_ptr の実装面での動作です．
567:デフォルトの名無しさん
07/01/08 03:42:00
>>566
うそ～ん？？shared_ptrはカウントを二種類持ってるってこと？
あ、sp_countと内部のweak_ptrの二種類のことを言ってる？？
568:デフォルトの名無しさん
07/01/08 04:04:00
>weak_ptr が1つ作られるごとに X の参照カウントのみが増やされ，
>weak_ptr が1つ破壊されるごとに X の参照カウントのみが減らされます．
shared_ptr<A> hoge(new A);
cout << hoge.use_count() << endl;
weak_ptr<A> hogehoge(hoge);
cout << hoge.use_count() << endl;
cout << hogehoge.use_count() << endl;
試してみたらどっちも増えなかったよ
569:デフォルトの名無しさん
07/01/08 10:57:47
>>568
weak_ptrのuse_countはweak_countを返すわけじゃないよ。
ドキュメント読め。
570:デフォルトの名無しさん
07/01/08 18:09:37
Boost.Timeseries
Boost.Accumrator
は結局アクセプトされたの？
571:デフォルトの名無しさん
07/01/09 13:46:37
オブジェクトを参照している最後の shared_ptr が破棄されるとき、
weak_ptr の有無にかかわらず、そのオブジェクトは削除される。
ただし、オブジェクトを参照する weak_ptr が存在していた場合、
参照カウントを保持する sp_counted_impl_pd は削除されない。
（weak_ptr と shared_ptr すべてが破棄されないと削除されない為）
weak_ptr からポインタ参照を行いたい場合、
必ずロックして shared_ptr を取得するような設計になってるけど、
上記仕組みのおかげで、たとえ shared_ptr が存在しない状態でも
オブジェクトが破棄されていることが分かり、エラーを返すことが出来る。
572:デフォルトの名無しさん
07/01/09 16:13:31
Statistical Distributions and Mathematical Special Functions
のレビューコメントが厳しいのばっかりなのはなんで？
最初 Boost.Mathとか名前ついてたときは、
ちょっと広すぎな名前だとは思ったけど
573:デフォルトの名無しさん
07/01/09 16:49:03
>>572
>Statistical Distributions and Mathematical Special Functions
興味あるんだけどどのへん見ればいいの？
ポインティングよろしく
574:デフォルトの名無しさん
07/01/09 17:14:44
URLﾘﾝｸ(boost-consulting.com)
の
math-toolkit-code.tar.bz2
575:デフォルトの名無しさん
07/01/09 17:25:00
>>574
Thanks!
576:デフォルトの名無しさん
07/01/09 18:12:22
>>548-571
通りすがりだけど、このやり取りで、weak_ptrがすっごくよく分かった！
日本語でこれだけちゃんとした説明はどこにもないと思う。ありがとう！
577:デフォルトの名無しさん
07/01/10 21:17:34
shared_ptrなんだけど、中にいれるオブジェクトが消えると
カウントが減りますよね。
でも、中のオブジェクトが消えたということを、shared_ptrはどうやって知るんですか？
代入演算子で上書きされたときについては、代入演算子の多重定義で
上書きされたほうをデクリメントしてるのは分かるんだけど、
スコープを抜けたときとかはshared_ptrには分からんのでは？
リアルタイムにオブジェクトが生きてるかどうかを監視してるわけでもないのに、
スコープ抜けてオブジェクトが自然消滅したときにもちゃんとカウントが
減ってるのって不思議すぎる。これ分かる人いる？
578:デフォルトの名無しさん
07/01/10 21:25:23
＞中にいれるオブジェクトが消える
＞代入演算子で上書きされたとき
＞オブジェクトが生きてるかどうか
この辺が果てしなく意味不明。
>>577はshared_ptrを全く理解していないようだ。
579:デフォルトの名無しさん
07/01/10 21:55:07
ソース読めばわかるよ
580:デフォルトの名無しさん
07/01/10 21:57:28
>577
デストラクタ
581:デフォルトの名無しさん
07/01/11 07:38:26
shared_ptr<A> hoge(new A);
int i = 1;
while(i--){
shared_ptr<A> hogehoge(new A);
hoge = hogehoge;
cout << hoge.use_count() << endl;
}
cout << hoge.use_count() << endl;
こういう状態のとき、二番目のhoge.use_count()のときにはカウントが
一番目より一つ減るでしょ。それをhogeのカウンタはどうやって把握したの？
ってことを聞きたかったんです。
カウンタのデクリメントについては、ソースを読めば代入演算子の
部分で、代入元をインクリメントして代入先をデクリメントするってことが
書いてあるけど、代入したオブジェクトそのものが上のコードみたいに
スコープはずれて消えたときにデクリメントする処理なんて書いてないな、
と思ったんです。
>>580
代入元のデストラクタですか？
どうやって代入元のデストラクタで、shared_ptrのカウントを下げてるか分かりますか？？
582:デフォルトの名無しさん
07/01/11 08:09:28
>>581
カウンタもshared_ptrが保持するポインタと同じく共有されるよ。
shared_ptr<A> hogehoge(new A); //カウント1
hoge = hogehoge; //カウント2
} //hogehogeの破棄によってカウント1
その後hogeの破棄時にカウントが0になるのでdeleteが呼ばれる。
583:デフォルトの名無しさん
07/01/11 09:19:43
初歩的な質問で申し訳ないけれど、
shared_ptrはコンストラクタではいろんなオブジェクトを受け付けるけど
代入はスマートポインタしか受け付けないってのは正しい？
いちど初期化してしまうと、
あとから別のオブジェクトを入れるには他のshared_ptrにいれてから
本当に入れたいshared_ptrにそのshared_ptrを代入するしかありませんか？
584:デフォルトの名無しさん
07/01/11 09:41:04
>>581
もうね、
＞ int i = 1
＞ while(i--){
の時点でC++理解してなさすぎ。
{
shared_ptr<A> hogehoge(new A);
hoge = hogehoge;
cout << hoge.use_count() << endl;
}
これだけでスコープ限定できるの。
boostを理解しようなんて百年早い。
基礎からやり直しな。
585:デフォルトの名無しさん
07/01/11 09:55:44
C++っていうかC
586:デフォルトの名無しさん
07/01/11 10:01:40
>>584
んなどうでもいいことよりも少しは本質的な話をしたらどう
587:デフォルトの名無しさん
07/01/11 10:03:37
do{
hogehoge();
}while(0);
hogehoge()は実行されますか？
588:デフォルトの名無しさん
07/01/11 10:28:53
>>587
それは別のスレで質問したらいいと思う
589:デフォルトの名無しさん
07/01/11 10:45:07
>>583
reset すれば？
590:デフォルトの名無しさん
07/01/11 10:47:47
お前らと仲良くなりたくて、もっと weak_ptr について理解を
深めようと思ったが、頭が悪すぎて理解できなかった。
なんかやばそうだから循環参照が起きないように気をつけよう、
その程度の理解な俺が作っているプログラムを使わされている
やつｶﾜｲｿｽ。
591:デフォルトの名無しさん
07/01/11 10:49:54
ちなみに俺の理解では weak_ptr は参照カウントを増減させないので
たとえ weak_ptr で参照されていたとしても実体が delete されて
いるかもしれん。だから weak_ptr の参照先が生きてるかどうか
ちゃんとチェックしてから使おうね、ってことなんだが。
592:デフォルトの名無しさん
07/01/11 10:51:18
生のポインタじゃなくて weak_ptr を使う理由は、
参照先のオブジェクトの生死を追跡することが出来るから。
えっと、ほかにうれしさある？
593:デフォルトの名無しさん
07/01/11 11:09:46
>>592
おれもよく分からんのだけど、読んだりしらべたりした感じだと
循環参照でカウントが不当に上がってしまわないように
shared_ptrの相互参照は片方をweak_ptrにしないと駄目ってことも
あるんじゃないだろうか。違ってたらまた指摘よろ
594:デフォルトの名無しさん
07/01/11 11:11:17
>>589
reset()か。ちょっと試してみる
595:デフォルトの名無しさん
07/01/11 11:24:52
>>589
reset()した後に、そのshared_ptrをどうやって再利用したらいいんだろう。
596:デフォルトの名無しさん
07/01/11 11:57:10
shared_ptrみたいな簡単な部類すら理解できないのに
boostを使おうなんて100年早い
597:デフォルトの名無しさん
07/01/11 12:08:07
>>596
それでも BGL は便利にがんがんつかわせてもらってます ＞＜
598:デフォルトの名無しさん
07/01/11 16:02:41
>>595
shared_ptr p1( object1 );
p1.reset( object2 );
shared_ptr のインターフェイス定義くらい読んでおけよ。
599:デフォルトの名無しさん
07/01/11 16:28:02
>>592
他に，対象のオブジェクトを参照している最中に
(そのオブジェクトを指している shared_ptr が全て消えることで)
突然そのオブジェクトが死んでしまうような事態を回避することができます．
(この問題はマルチスレッドプログラムで特に顕著だと思いますけれど，
シングルスレッドプログラムでも論理的にはありえるケースです)
void process( weak_ptr< Obj > wp )
{
if( shared_ptr< Obj > p = wp.lock() ){
// このスコープ内では， (たとえば他の実行スレッドの動作によって)
// p の指しているオブジェクトが削除されるようなことはない
}
else{
// wp が指しているオブジェクトが死んでいる場合．
// ここでどうするかは何を実装するかによります．
// wp の参照先が常に生存していることが不変条件ならば，
// 571さんの書いているように論理エラーを通知する (例外を送出する) ことに
// なるでしょうし，参照先のオブジェクトが死んでいることを検出して
// 他のアクションを取るようなことも，場合によっては想定されます．
}
}
600:デフォルトの名無しさん
07/01/11 16:30:05
また，自身は shared_ptr を必要としないけれど，他の誰かに
shared_ptr を渡すような要求がある場合に weak_ptr が必要になります．
// 自身は B のオブジェクトへの (弱い) 参照を持っているだけで良いが，
// B のオブジェクトへの shared_ptr を返すインタフェイスが必要なクラス
class A{
public:
shared_ptr< B > getB() const{ return boost::shared_ptr< B >( p_ ); }
private:
weak_ptr< B > p_;
};
あと weak_ptr の使い方として典型的なのが，参照先のオブジェクトが
死んでいてもかまわないような場合です． proxy (特にキャッシュの実装) や
observer などの実装で有用な使い方があるかと思います．
601:デフォルトの名無しさん
07/01/11 17:17:34
shared_ptr はソースはそんなに複雑ではないわりに、
enable_shared_from_this や、weak_ptr、shared_ptr<void>、カスタム削除子 への対応など
細かいところでさまざまな工夫が施されているから、一度ソースに目を通しておくと勉強になる。
602:デフォルトの名無しさん
07/01/11 19:49:50
削除子は勉強になったなぁ
603:デフォルトの名無しさん
07/01/11 20:18:15
今回の人の場合、ソース読むよりスマートポインタのことが書かれた
適当な本読んだほうがよくねえか？
いやおまいらが親切なのはよくわかったけどさ
604:デフォルトの名無しさん
07/01/11 20:31:23
カウンタを共有するのがポイント
605:デフォルトの名無しさん
07/01/11 20:56:40
>>603
＞適当な本読んだほうがよくねえか？
そういう本ある？自分は見たことないんだけれど
606:デフォルトの名無しさん
07/01/11 21:08:05
超定番ながらModern C++ Designじゃないかね？
607:デフォルトの名無しさん
07/01/11 22:49:52
multi_array<double,3>
じゃなくて
int ndim=3;
multi_array<double> a(ndim)
みたいな多次元配列の宣言の仕方できないのでしょうか？
ndimをプログラム中で変えたいのです
608:デフォルトの名無しさん
07/01/12 09:59:32
多次元配列の大きさを動的に決める方法なかったみたいなので
std::map< std::vector<double>, double> m
で代用しました。速度で問題でそうな雰囲気もするけど、しかたないかな・・・
609:デフォルトの名無しさん
07/01/12 11:07:32
>>608
ふつうstd::vector<<std::vector<double> >じゃない？
610:デフォルトの名無しさん
07/01/12 11:09:46
>>608
スレ違いになるが、一次元配列を(動的に)確保して、擬似多次元アクセス関数を作った方が善くないか?
611:デフォルトの名無しさん
07/01/12 11:32:19
>>606
boost::shared_ptr を理解する上で Modern C++ Design はどうなんですかね？
あれはスマートポインタについては，削除子による不完全型への対応とか
クロス DLL 問題などの突っ込んだ議論は載っていなかったように思いますし，
それに boost::shared_ptr の設計思想は， MC++D の一つの柱である
「ポリシーに基づく設計」のそれとは，アンチテーゼの関係にすらあるように思いますし．
612:デフォルトの名無しさん
07/01/12 15:50:59
>>608
…代用できるの？
613:デフォルトの名無しさん
07/01/12 21:54:17
どうみてもコンパイルエラーです。本当にありがとうございました。
614:デフォルトの名無しさん
07/01/12 23:21:36
>>611
標準C++ライブラリ(背表紙赤い奴)には auto_ptr の詳しい説明と
簡単なカウント式スマポの実装例があったような
あとは More Effective C++ とか？
615:デフォルトの名無しさん
07/01/15 10:15:05
「C++再考」のハンドルクラスの実装例なんか、どうっすかね？
616:デフォルトの名無しさん
07/01/15 17:01:38
boost.accumulators
いじってるんだけど、数値計算メインの人が
MPL勉強するのはちょっとしんどいんじゃないかと思うんだ
617:デフォルトの名無しさん
07/01/16 00:27:28
boostのヘッダーをインクルードすると、
バカみたいにコンパイル時間がかかるのですが、
メモリー増設すれば少しは早くなるのでしょうか？
Pentium M 17Ghz
Mem 500M
VS2005
OS:XP
です
コンパイルオプションをいじれば少しは早くなるのでしょうか？
618:デフォルトの名無しさん
07/01/16 00:30:17
CPUを速くしろ、と言おうと思ったが十分速いみたいだｗ
619:デフォルトの名無しさん
07/01/16 00:40:24
プリコンパイル済みヘッダ使えば多少はマシになんじゃない
17GHzもあるとどうかわからんけどｗ
620:デフォルトの名無しさん
07/01/16 00:46:42
1.7Ghzの間違いでした
コンパイル中に、やたらとディスクアクセスする音が聞こえるので
ひょっとして５００Ｍで足らないのかと思ったのですが、
そうでもないのですか？
621:デフォルトの名無しさん
07/01/16 01:12:45
そりゃヘッダ含めソースコードが置かれているのはディスクの中だからさ。
622:デフォルトの名無しさん
07/01/16 01:13:40
環境による。XPと開発環境以外何も入っていないのならspirit使わなければ500MBでも十分。
まあ500MBなんて半端なメモリ容量のPCは相当特殊だろうから俺の意見は参考にならんだろう。
512MBからビデオメモリ用に12MB引っ張ってくようなキモイ統合チップセットは聞いたことないし。
623:デフォルトの名無しさん
07/01/16 10:43:29
mplとかlambda使うならプリコンパイル済みヘッダは必須だな
624:デフォルトの名無しさん
07/01/16 10:51:49
テンプレートってコンパイル時まで型が決まらないからテンプレートなのに
プリコンパイルの効果あるの？
それとも全部のパターン分インスタンシエイトしちゃうとか？
625:デフォルトの名無しさん
07/01/16 13:01:41
>>624
2回目以降のコンパイル時には効果絶大だろ。
PCH が無いと、一度インスタンス化した型でもソースファイルが違うと
もう一度コンパイルしなきゃいけないし。
626:デフォルトの名無しさん
07/01/16 13:33:11
>>624
プリコンパイルっても別にオブジェクトコード吐くわけじゃなくて、
プリプロセッサ通して構文解析かけて、コンパイラの内部形式に変換しとく程度でも充分効果あるだろ。
627:デフォルトの名無しさん
07/01/16 14:06:43
いちいち stfafx.{cpp|h} みたいなのを作らないと
いけないのがめんどうだよな。hdrstop とかも指定せずに、
臨機応変にやってくれればいいのに。
って無茶か。
628:デフォルトの名無しさん
07/01/16 14:23:58
boost::serialization のシリアライズ先は
テキスト/バイナリ/XML なんだけど、
吐き出したデータを他の言語処理系から
読みたいときには XML しかないかな？
大量のデータを他の処理系とやりとりするときって、
やっぱり今まで通り独自形式で吐くしかないのかなぁ。
いっそのこと RDBMS のテーブルに吐き出してくれたらいいのに。
って、やっぱ自分で書き出すしかないか。
629:デフォルトの名無しさん
07/01/16 14:26:16
>>627
普通にcc foo.hするだけだろ。
630:デフォルトの名無しさん
07/01/16 21:42:08
RDBMSはランダムアクセスは早いがシーケンシャルが遅い。
そのうえ更新頻度が高いとシステムダウンする勢いでCPU負荷を上げ、
リソースを占有してしまう。
631:デフォルトの名無しさん
07/01/16 22:02:00
素直にXMLでいいや・・・
ところで、当たり前かも知れないけど
serialization って deserialization の方がコスト高いよね。
パースにかかるコストが高いんだろうけど。
632:デフォルトの名無しさん
07/01/16 22:40:36
軽く作ればパースはたいしたことはない。
普通の言語と違って構文がスゲー単純だから。
字句はDFAを使うとかすればいいかもしれない。
633:デフォルトの名無しさん
07/01/16 22:41:53
追記。たとえ重いパーサであってもRDBMSのODBCなどの
オーバーヘッドに比べれば屁の河童。
634:デフォルトの名無しさん
07/01/17 12:25:46
現在のバージョンの boost::serialization って、
特に XML にシリアライズする場合には浮動小数点数の
NaN が正しく扱われないんだな。
ちょっとカナシス。
635:デフォルトの名無しさん
07/01/18 02:26:24
浮動小数点といえば、IEEE754はそろそろバージョンうｐじゃなかったか
636:デフォルトの名無しさん
07/01/18 11:32:56
boost.decimal みたいなライブラリがほしいなぁ。
637:デフォルトの名無しさん
07/01/18 11:43:43
.NETはDecimal定数が扱えるのがぶっちゃけめちゃくちゃ便利だな。
複素数やリストもそうだけど、定数やリテラルとして使えるかどうかって
結局使い勝手に格段の差が出来ちまうな。
638:デフォルトの名無しさん
07/01/18 14:32:51
>>635
ｋｗｓｋ
639:デフォルトの名無しさん
07/01/18 15:25:16
>>638
URLﾘﾝｸ(ja.wikipedia.org)
640:デフォルトの名無しさん
07/01/18 15:33:30
>>639
ｔｈｘ
641:デフォルトの名無しさん
07/01/19 00:56:43
tuple と lambda を使ってみてたんだけど、
bind(&get<0>, _1);
って式が通らないんだが……。
返り型の指定してもダメだし、ドキュメントいくら読んでもさっぱりわからない。
誰か教えてくれないだろうか……(´・ω・`)
642:デフォルトの名無しさん
07/01/19 01:00:06
質問です。
クラスAとクラスBがあるとしてshared_ptrで相互参照するのはNGというのを最近知りました。
すると、相互参照したい場合は
class A{
weak_ptr<B> b;
}
class B{
shared_ptr<A> a;
}
とすれば良いのでしょうか。ちなみにAは一つしか存在しないBの管理クラスで、Bは複数存在する管理されるクラスなのですが、
その場合はこのように管理される側が管理する側をshared_ptrで参照して、管理する側が管理される側をweak_ptrで保持するのが良いのでしょうか。
あとscoped_ptrというのもあるようで、それぞれどういう時に利用すれば良いのかまだいまいち掴めません。
643:デフォルトの名無しさん
07/01/19 06:57:25
>>641
getは設計が古くなっている。
戻り値指定なしでもできるが長くなるのでこんな感じで
template<typename Result, int i>
struct get
{
/**/ typedef Result result_type;
/**/ template<typename Tuple>
/**/ Result operator()(Tuple& t) const
/**/ { return boost::get<i>(t); }
};
bind(get<double, 0>(), _1);
644:デフォルトの名無しさん
07/01/19 07:27:37
>>642
各オブジェクトの寿命を考えてみたらいいと思うよ。
あと、weak_ptrはオブジェクトを参照するときに
一時的なshared_ptrを作成するのでコストがかかるね。
scoped_ptr, scoped_arrayは、受け取ったポインタを
自分の寿命が切れるときにdeleteするだけのポインタクラス。
C++の仕様がわかっていれば使い道はいろいろ。
645:デフォルトの名無しさん
07/01/19 14:15:52
で、いつ標準化されるんですかね。
646:デフォルトの名無しさん
07/01/20 00:52:42
>>643
おお、ありがとう。
やっぱり戻り値の型が判別できないのが問題なのかな？
色々いじりつつ、もう一度 lambda の sig を読んでみたら、今度はちょっと分かった気が。
template <int i>
struct get {
/**/ template <class Tuple>
/**/ typename boost::tuples::element<i, Tuple>::type operator()(Tuple& t) const {
/******/ return boost::get<i>(t);
/**/ }
/**/ template <class Args>
/**/ class sig {
/******/ typedef typename boost::tuples::element<1, Args>::type Tuple;
/******/ typedef typename boost::tuples::element<i, Tuple>::type Result;
/**/ public:
/******/ typedef typename boost::remove_cv<Result>::type type;
/**/ };
};
bind(get<0>(), _1);
ってことで、こう書いたらとりあえず行けたんだが、こんな感じでいいのかな？
もっといいやり方があったりするんだろうか。
しかし、関数オブジェクトならこれでいい（？）けど、テンプレート関数には sig は使えないよね。
ということは、関数の場合はテンプレート引数を全部指定しないとダメってことかな。
いや、でも、boost::get<> のテンプレート引数全部指定してもダメだったし、キャストしてもムリだったような。
なんかまたよくわからなくなってきた…(´・ω・`)
647:デフォルトの名無しさん
07/01/20 11:19:05
引数指定が間違ってるんだろう。consとかいるぞ
そもそもgetのシグニチャーは公開されてないと思われるので書いてはいけない。
要は君の::getが主役で、boost::getはシンタックスシュガーだ
関数オブジェクトがつねに偉いのだ
648:デフォルトの名無しさん
07/01/21 20:32:31
bindで結合されたオブジェクトをfor_eachで適用するとき,適用されたオブジェクトを取り出すには
for_eachの結果を何に代入すればいいのでしょうか？
struct fn1
{
double sum;
void operator()(double &t )
{sum += t;}
}
fn1.sum=0;
何に代入したらオブジェクトfn1を取り出せる？
=for_each(ar.begin(),ar.end(),
boost::bind( fn1,
boost::bind(fn2,_1 ))
);
代入しないと
fn1.sum==0
となる
649:デフォルトの名無しさん
07/01/21 20:41:39
>>648
bind() された関数オブジェクトの型は決められていないから、無理。
かわりに、結果の書き込み先を参照で持たせるのがいいんじゃない？
総和なら std::accumulate() 使えばいいんだけどね。
ソース貼るならコンパイルできるかどうか見直せよ。
650:デフォルトの名無しさん
07/01/21 20:48:45
boost::bind(boost::ref(fn1),
651:デフォルトの名無しさん
07/01/21 20:52:54
>>650
できました
感謝
652:デフォルトの名無しさん
07/01/22 01:40:45
lambda
のtestコード
algorithm_test.cpp
がMSVC8でコンパイル通らない
653:デフォルトの名無しさん
07/01/22 03:06:39
>>649←恥ずかしい人ﾊｹﾝ
654:デフォルトの名無しさん
07/01/22 06:14:33
よかったね。毎日が発見の連続だね。
655:649
07/01/22 07:01:48
ん？何か変なこと言ったか？
656:デフォルトの名無しさん
07/01/22 16:11:33
みなさん、boost::FileSystemって使ってます？
日本語対応してないとかmingwで一部テストがエラーとか、ちょっと使うのに二の足踏んでます。
でも移植性のある他の代替選択肢もなさそうだしなぁ・・・。
657:デフォルトの名無しさん
07/01/22 16:39:05
>> でも移植性のある他の代替選択肢もなさそうだしなぁ・・・。
boost以外のポータブルなライブラリを使えばよいのでは。
ファイルシステム関連でMBCS/WCSに対応してないって、実用上論外だと思うが。
Shift_JIS環境では使い物にならないし、Win32のFindFirstFileA()って
パス長に思いっきり制限あるし。
658:デフォルトの名無しさん
07/01/22 17:16:19
CVSから1.34拾ってこい。
659:デフォルトの名無しさん
07/01/22 17:47:54
がらっと変わってるよね
念願の basic_path 化とか他盛りだくさん
URLﾘﾝｸ(boost.cvs.sourceforge.net)
660:デフォルトの名無しさん
07/01/22 19:35:35
1.34 早くリリースされないかな？
661:デフォルトの名無しさん
07/01/22 21:28:32
1.35は大変なことになるというか、もう別の言語というか
Fusion, MPI, Asio, Interprocessなどなど
ライブラリに関しては、標準が何かするべきではないと思う
標準は、発表の場を提供することに予算を使うべきだ。
そして、その場所を標準として定義すべきだ(とか言ってしまおう)
実際stlportが泥を被っているわけだしな
BoostがなければC++は死んでたよ
662:デフォルトの名無しさん
07/01/22 22:11:32
>>661
すまんが言いたいことがよくわからん。
もうちょっと具体的 and/or 他人に理解できるようにお願い。
663:デフォルトの名無しさん
07/01/22 22:40:02
signalを関数objectとしてfor_eachに渡す方法はないのでしょうか？
struct obj1
{
void operator()(double &t) const
{std::cout << "obj1:" << t << " " ;}
};
struct obj2
{
void operator()(double &t) const
{std::cout << "obj2:" << t << " " ;}
};
boost::signal1< void ,double> sig;
sig.connect(obj1());
sig.connect(obj2());
std::vector<double > ar;
std::for_each(ar.begin(),ar.end(),sig)
err sigのプライベートメンバーにアクセスできません
となってfor_eachに渡せません
単にobj1,2を両方使いたいだけなんだけど
664:663
07/01/22 22:56:26
自己解決しました
std::for_each(ar.begin(),ar.end(),boost::bind<void>(boost::ref(sig), _1));
でできました
665:デフォルトの名無しさん
07/01/24 09:21:05
gil::transform_channels(pixel1,pixel2,pixel3, ( 1.0/(boost::lambda::_1 - boost::lambda::_2) ) );
がコンパイルエラーになるのですが、
何か見落としているのでしょうか？
666:665
07/01/24 09:51:28
エラーの原因
gil::transform_channels(pixel1, pixel2, pixel3
を使ってるはずが lambdaを使ったとたん
gil::transform_channels(const pixel1,const pixel2, pixel3
に入れ替わってしまうことが原因のようです
667:665
07/01/24 09:52:00
gil::transform_channels(pixel1,pixel2,pixel3, std::plus<double>() );
とするとコンパイルは通ります
668:デフォルトの名無しさん
07/01/24 10:50:48
MSVC++7.1, boost1.33.1の環境です。
URLﾘﾝｸ(kansai2channeler.hp.infoseek.co.jp)
のコードを実行すると、自分の環境では
boost::regex_search()で例外が発生してしまいます。
("Memory exhausted").
これはboost:regexのバグでしょうか。対処方法はありますか。
別にやっていること自体は大したことでは無いはずです。
（このパターンはこの入力に対してはマッチしません）。
C＃, Java, JScript, ICU, 鬼車, 等々で、全く同じ正規表現と入力を用いて
同等のパターンマッチを試みても、何の問題も発生しないことは確認済みです。
669:デフォルトの名無しさん
07/01/24 12:43:19
そんなことより文章のほうに目がいった
670:デフォルトの名無しさん
07/01/24 13:00:18
エロかとおもったら三四郎じゃないすか
671:デフォルトの名無しさん
07/01/24 22:55:12
boost のヘッダは <boost/...hpp> と "boost/...hpp" と、どちらがお勧めですか？
672:デフォルトの名無しさん
07/01/24 23:14:27
後者は書かないことをすすめる
673:デフォルトの名無しさん
07/01/24 23:20:45
>>672
なんで？ <...> は標準ヘッダでしょ？
boost は標準じゃないから "..." だと思うよ。
674:デフォルトの名無しさん
07/01/25 00:02:55
>>673
くだすれC言語（初心者用）
ｽﾚﾘﾝｸ(tech板)
675:デフォルトの名無しさん
07/01/25 00:03:34
>>673
<>と""の違いは、ファイル探索順の違いしかないと思ったが。
676:668
07/01/25 00:05:11
えーと、つまり俺の問題は俺の環境のみで起きるのであって、そんなもん
知るかヴォケ、悔しかったらboost::regexなんぞに頼らず
テメェがDFAとかNFAとか書きやがれ。
ということでよろしいでしょうか。
このタイプの正規表現で、入力量の大きい時にコケる、という印象なのですが。
677:デフォルトの名無しさん
07/01/25 00:06:17
個人的にはプロジェクト内のものは " "、プロジェクト外のものは < > にしてる。
つまり <boost/....hpp> 派だな。
678:デフォルトの名無しさん
07/01/25 00:08:08
>>676
君のプログラムを試したわけはないが VC7 ってとこにちょっと引っ掛かる。
可能であれば VC8 とか cygwin/mingw とかで試してみなはれ。
679:668
07/01/25 00:13:15
>>678
VC8は持ってないんすよ。
localeまわりでstd::wcoutが腐るとかfstream::open()が上手くいかねーとか
腐った風評しか聞きませんので、移行するとしても二の足を踏んでしまいますが。
VC7.1をboostはサポートしていないのですか？
680:デフォルトの名無しさん
07/01/25 00:16:42
VC8でも同じ例外発生したよん。
681:デフォルトの名無しさん
07/01/25 02:33:59
bindが必要とするresult_typeを
sig templateで代用することはできないのでしょうか？
682:デフォルトの名無しさん
07/01/26 06:33:13
MPLで次元解析する方法みて感動したけど、
いざ自分の問題で使おうと思っても、使いどころが微妙
いり込んだ type の木構造でも使わない限り
enable_ifの延長としてしか使えない
683:デフォルトの名無しさん
07/01/26 20:40:23
boost::bindを
boost::lambda::bind
に変えたら挙動が違う
protectで囲ってあるところを呼んだり呼ばないで落ちたり
どっちのbinsを使うのが推奨なの？
684:デフォルトの名無しさん
07/01/27 00:47:54
>>668
の問題に関して：
URLﾘﾝｸ(capslockabcjp.kitunebi.com)
boostのバグ?
スレでの指摘により、boostの動作が怪しいという指摘がありました。
boost1.33および1.33.1で/\1/を使用した場合に落ちることを確認しました。
685:デフォルトの名無しさん
07/01/27 19:43:57
boostがC++でC++のコンパイラ作るのはいつ？
686:デフォルトの名無しさん
07/01/27 20:43:41
spiritでC++のコンパイラ書けってことか
687:デフォルトの名無しさん
07/01/28 03:04:59
Boostのおなじみの形式のドキュメント
こんなやつをdoxgenみたいに自動生成するツールってないのかな
URLﾘﾝｸ(boost-sandbox.sourceforge.net)
688:デフォルトの名無しさん
07/01/28 16:49:09
ヘッダーファイルの置き場所について教えてください
既存のboostの拡張として
boost/X/Y/z.hpp
に、おきたくなるようなヘッダーがあります。
しかしboost MLに投稿してもrejectされる可能性を考えて
my_lib_name/X/Y/z.hpp
においておくべきか,どうかで迷ってます
ヘッダーの場所を
#define my_lib_name/X/Y/z.hpp INC_XYZ
として後で変更できるようにしておくのが無難なのでしょうか？
namespaceも
boost::X::Y::z
などとせず
#define my_lib_name::X::Y::z NAME_XYZ
としておくのが無難なのでしょうか？
689:デフォルトの名無しさん
07/01/28 17:22:21
>>688
boost 気にすんな。紛らわしい。
どうせ accept されないし。
書き換えるにしてもたいした手間じゃない。
690:デフォルトの名無しさん
07/01/29 16:44:56
>>671
確か、mingwで使おうと思ったときに""だとどうしてもエラーになった気がする。
それ以後ずっと<>にしてる。
""で行けている人居る？
691:デフォルトの名無しさん
07/01/29 17:58:52
#define BOOST_DIR c:/lib/boost_ver_xxx/
#define BOOST_BIND_INC BOOST_DIR##bind.hpp
うまくいかない
#include "BOOST_BIND_INC "
うまくいくのかな？
#include <BOOST_BIND_INC >
692:デフォルトの名無しさん
07/01/29 18:04:41
Makefileの先頭で
INCLUDE=C:/boost
LIB=C:/boost/mingw
こんなんでいけたはず。
というかUNIXルーツのソフトのお約束で常識だったはず。
x.ccをコンパイルする時はこうだった思う。
A>echo "INCLUDE=C:/boost">Makefile
A>echo "LIB=C:/boost/mingw">>Makefile
A>gmake x
693:デフォルトの名無しさん
07/01/29 18:25:49
>>691
それをやるならこんな感じ。
# define BOOST_DIR c:/lib/boost_ver_xxx/
# define PP_IDENTITY(x) x
# define PP_STRINGIZE(x) PP_STRINGIZE_I(x)
# define PP_STRINGIZE_I(x) #x
# define BOOST_INC(name) PP_STRINGIZE(PP_IDENTITY(BOOST_DIR)name)
# include BOOST_INC(bind.hpp)
694:デフォルトの名無しさん
07/01/29 23:43:27
>>691
ちょｗ
695:デフォルトの名無しさん
07/01/30 19:16:12
ヨーロッパ系の人の作るライブラリーにboostが使われないのは
ライセンスの関係？単なる好み？
696:デフォルトの名無しさん
07/01/30 21:58:14
変なレビュー投稿しちまった
697:デフォルトの名無しさん
07/01/31 05:06:16
spiritって、もしかしてUnicodeは対応してない？
698:デフォルトの名無しさん
07/01/31 11:15:53
いや、普通にいけるはず。
Unicodeのtextファイル相手にfile_iterator使ってる場合はBOMに注意。
699:デフォルトの名無しさん
07/01/31 11:51:17
さんクスコ
700:デフォルトの名無しさん
07/02/02 23:37:31
boost::tuples::get<0>をbindしたいのですが
なぜかうまくいきません。
struct tmp_bi_op_t
{
double sum;
double operator()(double a ,double b)
{
sum +=a+b;
std::cout << "(" <<a << " " <<b << " " << sum << ")";
return a+b;
}
};
tmp_bi_op_t tmp_bi_op;
tmp_bi_op.sum=0;
std::vector<double > vec,vec2(2);
vec.push_back(2);
vec.push_back(1);
std::for_each(
boost::make_zip_iterator(
boost::make_tuple(vec.begin(), vec.begin())
),
boost::make_zip_iterator(
boost::make_tuple(vec.end(), vec.end())
),
boost::bind<void>( boost::ref( tmp_bi_op),
boost::bind(boost::tuples::get<0>,_1),
boost::bind(boost::tuples::get<1>,_1)));
std::cout << tmp_bi_op.sum;
701:デフォルトの名無しさん
07/02/08 22:12:27
こんにちは
vista+vc2005環境にboostを組み込みたいんですけどうまく行きません
何が原因なんでしょうか・・以下の手順で駄目でした
まずboost1_33_1とjamを落とし展開、jamをboostフォルダに移動し、
コマンドプロンプトで以下を実行
（boostのフォルダ以下略）>"C:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat"
bjam -sTOOLS=vc-8_0 --prefix="C:\Program Files\Microsoft Visual Studio 8\VC" install
すると一見快調にビルドしてるようでしたが>>380氏と同様のエラーが頻発していて、
かつ「Unicodeで保存してください」ワーニングも量産されてました
6.0では組み込みが成功していたんですが、そのときコンパイラに組み込んでいた
（VCのフォルダ）\INCLUDE\boost-1_33_1みたいなフォルダは生成されてませんでした
次に>>391のサイトにあるインストーラを試してみましたがこれも例のフォルダは見当たらず・・
ひょっとしてvc2005ではboostの組み込み方が違っていて
私は壮大な勘違いをしてるんでしょうか？
今日一日かけて調べてみましたが全然分かりません
どうかよろしくお願いしますm(_ _;;)m
702:デフォルトの名無しさん
07/02/08 23:22:12
>>701
391さんのお任せのやつなら、
VC8.0用を指定して展開位置を指定するとそこににboost-1-33-1のディレクトリが出来ているので、
その中にboostがあるから、自分のプロジェクトのインクルードディレクトリに追加指定すれば
よいかと思いますけど。リンク対象のライブラリ本体はlibの中にバイナリが入ってます。
VCのINCLUDEに入れたければ、boostフォルダごとコピーすれば使えるのはないですか？
VCのLIBにもlibの中身をコピーして。
見当違いでしたら、すみません。
703:デフォルトの名無しさん
07/02/09 19:15:31
>>702
レスありがとうございます。
それでいいんですね、VC6.0でいけてたときは自動でVC以下にフォルダが
できてたような気がしたので、てっきり失敗してるのかと思ってました。
で、プロジェクトにインクルードとライブラリのフォルダを追加したのですが・・・
どうやらboostを認識してるようですがまたもや意味不明のエラーが多量にorz
SP1適用もなんかうまくいってないようなのでもう一度よく調べて出直してきます
704:デフォルトの名無しさん
07/02/09 19:41:07
公式サイトのゲッティング スタートからvc8.0のリンクから飛んだ先にEEのときがある
規制中なので携帯からリンク貼れね
705:デフォルトの名無しさん
07/02/09 19:55:20
>>702
コピーしなくてもいいだろ。
706:デフォルトの名無しさん
07/02/09 20:02:16
ビルドしたboostフォルダは1GB超えるからな
707:デフォルトの名無しさん
07/02/10 21:11:13
C++の標準ライブラリになるまでは様子見だな。
708:デフォルトの名無しさん
07/02/10 22:22:59
Boostがまんま標準化されると思ってる奴がまだいるのか
709:デフォルトの名無しさん
07/02/10 22:45:21
だから様子見なんだろ
710:デフォルトの名無しさん
07/02/10 23:58:59
>>703
俺は、C直下にboost_1_33_1のフォルダ入れて
VS2005std使ってて
VC++のインクルードディレクトリにC\boost_1_33_1
ライブラリファイルフォルダにC\boost_1_33_1\lib
って設定したら、問題なく使えてる。
711:デフォルトの名無しさん
07/02/11 20:27:53
boostのリビューアー募集してるね
712:デフォルトの名無しさん
07/02/13 13:33:23
Xpressive の人のライブラリか？
何かスゲーな。
713:デフォルトの名無しさん
07/02/18 00:37:48
serializationでshared_ptrをシリアライズしようと思ってるんですけど訳分からんです。
とりあえずただの参照でテストしてみたら
unregistered_classが発生したので調べたとおりに
BOOST_CLASS_EXPORT(Derived);
を入れたら今度はunregistered_castが発生したのでいろいろ調べて
boost::serialization::void_cast_register<Derived, Base>(0, 0);
を入れたらただの参照ならシリアライズできるようになりました。
これを今度はshared_ptrに入れてみようかと思ったら
またもやunregistered_classが発生しました。
どうやらsp_counted_base_implとかいうのが絡んでるようで
いろいろ試してみたのですがなかなかうまくいきません。
boost_132::shared_ptrとかいう中途半端なものもあるみたいですけど
これはもしかしたら仕様策定中ですか？
714:713
07/02/19 18:24:41
すいません。抜けてました。
派生クラスをベースクラスのポインタでシリアライズしたいのです。
バージョンは1.33.1です。
715:デフォルトの名無しさん
07/02/21 18:45:54
Accumulatorsの仕様がもう一回変わるとかいってるのですが
もう自分のプログラムにいれちゃったよ
716:デフォルトの名無しさん
07/02/22 10:40:57
TR1、TR2、C++0xとboostの主機能が取り込まれるのを期待しているが、
実際C++0xが2010年位にできたとして、実際主なコンパイラがサポートしだすのは
いつになるんだろう。
GCCは期待できるとして、次期Visual C++で何も動きがないとすると、
結局今後５年くらいはshared_ptrつかうにもboostのお世話になったりして。
1_34いつになるのかなぁ・・・。
717:デフォルトの名無しさん
07/02/22 10:57:48
規格殺すにゃ刃物はいらぬ
MSのサポートがなけりゃいい
718:デフォルトの名無しさん
07/02/22 11:05:36
つか、MSがその頃までC++をサポートしてるかどうか
719:デフォルトの名無しさん
07/02/22 12:26:40
今となっては TR1,TR2 以外のライブラリも増えたんで主機能という風でもないような。
C++0x 後にゃ、今度はその新機能を使いまくりのライブラリが作られるだろうし。
720:デフォルトの名無しさん
07/02/22 14:13:29
>>718
ドライバとか、どうしてもC/C++が必要な領域もあるだろうから、
当分はVisualC++無くならないと思う。たぶん。
721:デフォルトの名無しさん
07/02/22 14:17:11
いずれはドライバも C# の unsafe 使って書いてくれとか言われるのかなｗ
722:713
07/02/23 19:57:51
どうにか自己解決しました。
デバッグのためのコードが邪魔してたみたいです。
スレ汚しすいませんでした。
723:デフォルトの名無しさん
07/02/25 01:32:35
以前スレで紹介されていたBoostのインストーラーを使いセットアップし、regexを使ってソースを書いたところ、Boost側のソースで
boost\regex\v4\regex_raw_buffer.hpp(177) : error C2661: 'operator new' : 3 個の引数を伴うオーバーロードされた関数はありません。
boost\regex\v4\perl_matcher_non_recursive.hpp(99) : error C2059: 構文エラー : '*'
というエラーが出たんですが、どうすれば直るんでしょうか？
コンパイラはVC++2005Expressです。
724:723
07/02/26 23:31:23
自己解決。
stdafx.hで
#include <boost/regex.hpp>
すればOKだった。
725:デフォルトの名無しさん
07/02/26 23:58:53
boostって何で流行らないの？糞だから？
726:デフォルトの名無しさん
07/02/27 00:06:08
流行ってると思うけど
727:デフォルトの名無しさん
07/02/27 08:26:44
俺だけ取り残されてるわけじゃないんだ！ という
必死の念仏でしょう。
728:デフォルトの名無しさん
07/02/27 14:38:27
常に最新の boost を使いたい場合は、
CVS から定期的に取って来て自動的にビルド、
エラー無ければ直前のバージョンと入れ替え、
というようなシステムを自前で用意しないとダメ？
PHP の PEAR のようにリポジトリから
最新バージョンを持ってきてくれると便利なんだが。
って、スクリプト言語の手軽さと比較するほうが間違いか。
729:デフォルトの名無しさん
07/02/27 21:30:35
Visual Studio用にバイナリで配ってない時点で、流行ってないことは明らかだろ。
730:デフォルトの名無しさん
07/02/27 21:58:05
流行っているといえば流行っている
流行っていないといえば流行っていない
結構微妙な位置づけな気がする
巨大な非標準ライブラリってだけで、使いにくい局面は多いよな
731:デフォルトの名無しさん
07/02/27 22:03:29
>>729
bjamの宣伝をしたいからじゃね？
732:デフォルトの名無しさん
07/02/27 22:05:00
対応してるコンパイラが何十種類もあるのにVC++だけ特別扱いするわけにはいかんだろう
733:デフォルトの名無しさん
07/02/27 22:11:59
デバッグ・リリース、静的・動的リンクの
全ての組み合わせのLIB/DLLを合計すると軽く1GiB超えていた覚えがある。
でも今確かめてみたらDLLとそのインポートライブラリに限れば、
10MiB以下に収まっている（1.33.1のVC++ 7.1でのビルド）。
俺は動的リンク版が無いもの以外静的ライブラリを削除しているのだが、
残った静的ライブラリの合計は、およそ221MiB。
（ただしNTFSの圧縮でディスク上は68.5MiBとなっている）
734:デフォルトの名無しさん
07/02/28 00:19:33
>>732
ユーザが多い順にバイナリくらい提供した方がいいだろ。
735:デフォルトの名無しさん
07/02/28 00:26:46
流行ってるかどうかとはあまり関係ない話だな
736:デフォルトの名無しさん
07/02/28 01:08:04
>734
馬鹿除けになるからバイナリは無い方がいい。bjamぐらい使え。
そもそもバイナリ必要なのは一部だけだし。
737:デフォルトの名無しさん
07/02/28 01:09:49
無いと困るような人とその存在すら知らない人が同じフロアで仕事してる
つうか技術寄りな人が勝手に調べて喜んで使ってる感じ
738:デフォルトの名無しさん
07/02/28 10:24:58
VCユーザなら、こっからinstaller落とせるけど。
URLﾘﾝｸ(www.boost-consulting.com)