C++ Ramble

メモリに乗り切らない巨大コンテナとそれに対するアルゴリズム

http://thread.gmane.org/gmane.comp.lib.boost.devel/117538
っていうか,こういうのが出てくるの待ってたのだ.

quickbook

http://article.gmane.org/gmane.comp.lib.boost.devel/117531
quickbook後でチェックしておこうっと.

boost::function_traitsがMPLのメタ関数の書き方に統一

http://thread.gmane.org/gmane.comp.lib.boost.devel/117620
ようやくって感じだべ.

shared_ptrのスレッド安全性

http://thread.gmane.org/gmane.comp.lib.boost.devel/117888
自分,マルチスレッドプログラミングについてはきちんと勉強したことないからにゃあ.一度ちゃんと勉強したいんだけれど.

(強い)例外安全性にこだわり過ぎないよ〜に

http://thread.gmane.org/gmane.comp.lib.boost.devel/118009
http://article.gmane.org/gmane.comp.lib.boost.devel/118085
そんなふうに考えていた時期が俺にもありましたAA略).っていうかこういう話が読めるのが面白いんだよな,boost.develは.そ〜言えばcomp.lang.c++.moderatedのポストに「早まった最適化 (Premature Optimization)」・「早まった一般化 (Premature Generalization)」と並べて「早まった例外安全性の強化」を挙げているのがあったにゃあ.

なぜboost::shared_ptrは重いのか

http://article.gmane.org/gmane.comp.lib.boost.devel/116983
このスレッド読んでようやくshared_ptrの立場を理解した(つもり).要するにshared_ptrにはパフォーマンスやcustomizationよりも優先するべきものがあるっちゅーことなんだな.特にライブラリ境界を越えるような場合などで,ライブラリを提供する側とライブラリをしようする側で容易にコンセンサスが取れるような標準としてのスマートポインタクラスを提供するというのが第1義ってところか.そして将来的には標準に入るけれど,標準に入ることそれ自身に意味があるというか,標準に入ることによって標準スマートポインタクラスの地位をより確実にできるというところか.そういう立場のクラスではパフォーマンスよりもほとんどの場合で安全かつ確実に動くことが優先されると.速いスマートポインタクラスを再発明するのは簡単だけれど安全なスマートポインタを再発明するのは労力がかかる(だからこそ効率よりも安全性と簡便性を優先したスマートポインタを提供する)という理由も十分納得できる.

You are absolutely correct that sometimes you can get away with a simpler smart pointer that carries less overhead. The emphasis in shared_ptr's case is on correctness and expressive power over efficiency, because (IMO) the first two provide more value in a standard smart pointer, since they are much more harder to reinvent. The good thing is that once you have a stable design, efficiency usually follows, as happened here.

http://article.gmane.org/gmane.comp.lib.boost.devel/117014

テンプレート引数を多数用意したポリシーベースの設計も,こういう立場のクラスにおいては(特にそういった設計・実装を熟知していない人間の)誤用を招くという意味と,標準のスマートポインタとしての役割を希薄化するという2つの意味で危険であると.
む〜,汎用性と効率を両立できてばんじゃ〜いなポリシーベース設計に対する大きなアンチテーゼだにゃあ.難しいもんだのぉ.

Adobe Open source Library

http://thread.gmane.org/gmane.comp.lib.boost.devel/118845
Adobe Open Source LibraryがBoostライクな技法やヘビーなテンプレートの使い方をやってるという内容.自分,Boostやテンプレートの技法に強く依存したコードを書くのって結構遠慮してしまうんだけれど,これで少しは「Adobeもやってる」っていうのを免罪符に出来るかな?

From Herb Sutter's operator=? to big int

http://thread.gmane.org/gmane.comp.lib.boost.devel/118958
ワシも"Exceptional C++"で知ったんだよねぇ,このoperator=.でも,この話ってETやmove semanticsの話になりそうな気がするんだけどな.スレッドでかいから全部追えない・・・.後半はBig Intの話になってるし.ワシも昔作ったなぁ.RSA暗号作りたくてそれ用に.クソ遅かった・・・.せっかくFFTによる高速乗算組んだのに普通の乗算より有利になるのが数100万桁以上からだと知ってしょぼ〜んとか色々あったなぁ(遠い目).

Unhackable Wiki

http://thread.gmane.org/gmane.comp.lib.boost.devel/119055
なるほどねー.もし将来publicなWikiを立てる機会があったら是非とも参考にさせていただきますわ,すわすわ.

PMFJI

http://article.gmane.org/gmane.comp.lib.boost.devel/119061
"PMFJI"って何よ?と思ったら
http://article.gmane.org/gmane.comp.lib.boost.devel/119089
"Perdon Me For Jumping In"ね.「割り込んでごめんだけれど」ってところか.後続の接続詞はsorryとかと同じくbutと.

「ど〜でも良いことに全力を注ぐ」は私のモットーでもあります

http://thread.gmane.org/gmane.comp.lib.boost.devel/119209
「optionalを出力する」というたったそれだけのことにこんだけの議論が展開されるっていうのがいいなぁw

抽象化とプラットフォーム依存

http://thread.gmane.org/gmane.comp.lib.boost.devel/119180
これ永遠のテーマだと思うんだけれどな.プラットフォーム非依存なコードを書くというのは本当に難しいにゃあ.

ハッシュ関数ライブラリレビュー開始

http://thread.gmane.org/gmane.comp.lib.boost.devel/119433
unordered setを始めとしてハッシュ関数が必要となる場面は多いからにゃあ.このスレッドの議論は後学のためにもぜひ読んでおかにゃいと.
// hdn