以下読書感想文なのかただの愚痴なのか良く分からない文章．
何で多くの実装でvector / deque等のexponential growth strategyの拡張係数が2じゃなくて1.5なのか？という謎が解けた・・・解けたのか？大元のコラム（Andrew Koenigの1998年9月のJournal of Object-Oriented Programmingのコラム）が読みたいけれど，今はもう手に入らないのかねぇ．
COWなstringで，operator[]経由で参照が取られたりiteratorが取られたらどないすんねん，という話でてっきりプロクシの話になると思っていたら，内部ハンドルが取られたことをオブザーブしておいてその間はshareを禁止しておいて，mutatingな操作がされたときに再びsharableにする，という戦略が「( ・∀・)つ〃∩ ヘェーヘェーヘェー」だった．もちろんドキュメントには一言「mutatingな操作がなされたらiteratorなどの内部ハンドルは全て無効化される」．うみゅ．(・∀・)イイ!．というか今までこの方法についてのちゃんとした議論に自分がお目にかかっていなかったことが不思議．
＃というか短く文章で書くと何のことか意味不明だ・・・
マルチスレッドだとやっぱCOWの良さはほとんどないのね．
std::uncaught_exceptionについての一言"My advice: Don't use it."にワラタ．
初期化子リストから飛んでくる例外を捕まえる構文をこの本で初めて知って驚いた．大概の構文は制覇したつもりでいたのですごいショックだったｗ．
諸々の副作用を無視して変更しようとしているオブジェクトだけに対する強い例外安全性を"Local strong guarantee"っつー言葉で呼んでた．これはこれで良いけれど，汎用プログラミングの場合の例外安全性の範疇（どこまでのロールバックを保証するのか・すべきなのか）がいまいち分からんのだよな．以前某所でも話題に上がっていたけれど．
"Siamese Twin Problem"（多重継承で違う基底クラスに同じシグネチャの仮想関数が2つあったらどうしましょうか問題）なんてのあるのねん．
publicなインターフェースは非仮想関数にしてprivateな仮想関数を呼ぶってパターンはなるほどよく議論を読んでみれば説得力があると思った．
http://www.gotw.ca/publications/mill18.htm
（ていうかこの記事指すの2回目ですな．）template methodパターンね．仮想関数はあくまでhookerだという立場かな．最近streamやlocale周りをちゃんとみてみて分かったことだけれど，標準ライブラリで仮想関数使う場面ではすべからくこの設計になっているのはちょっと( ・∀・)つ〃∩ ヘェーヘェーヘェーだったにゃあ．あとデストラクタの設計指針は分かりやすいなぁ．
純粋仮想関数に定義を書く，というのを見て最初はかなり(゜Д゜)ハァ?だったのは内緒だよぉ？
