むぅ〜，いつかは起こるであろうと思われた問題がついに起きた，ということなのでしょうが・・・・よりによって最も難しく，最も厳しい形で起きてしまいましたねぇ．
P.S. あ，書き忘れていましたけれど，私は自衛隊撤退に反対ですよ．しかし，この意見が，”あくまで1個人の人間感情として捉えれば”「見殺しにしろ」という主張になんら変わりがないというところが難しいところだと思うのです．地球より重く鴻毛より軽い・・・
先達のお言葉
http://lists.boost.org/MailArchives/boost/msg29087.php
当たり前のこと言ってるはずなんだけどこの人が言うと説得力が違う．
効率は一度失うと2度と戻らない・・・．自分が漠然と思っていたことを，はっきりとした言葉にしてくれるのは本当にありがたい．
ちなみに自分が最初にこのことを漠然と認識したのは，deallocateにsizeとして0を渡すと落ちるという現象に出会ったとき．このときに，libraryは0に対して安全ではないが効率は良い形で実装にしておいて，userの側で（必要があれば効率を犠牲にして）0でないことを保証させる仕様にしているんだろうと思った．しかし，逆にlibraryの側で0でないことを保証し，そのためにoverheadを払う実装であったとすれば，もはやuserにはどうすることもできない．ちなみに標準でdeallocateに0を渡したときの振る舞いについてどう書いているかは，今手元に規格書がないのでちょっと分からない．
この部分はlibrary実装者に向けての言葉だけれど，私のような1 userでもlibraryを使う上でPolicyの存在意義を知っておくのは重要ですわな．それから，libraryの実装者じゃなくても「hardcordingをなるべく遅らせたい」ってことは良くある事で，他との複合的な部分の兼ね合いから実装詳細を決めたい場合なんて多々あるから，そういうときに詳細の意思決定を効率を落とすことなく遅延できるというのはすばらしいと思うがどうか？（あれ？これってMC++Dの受け売りだっけか？ｗ）
P.S. っていうかchained inheritanceが普通に出てきてますねｗ
P.S.2. template typedefには皆さん期待しているんですねぇ．ようやくこれの真価が分かりました．partial specializationと併用するとえげつないことになりますな．早く標準に入らないかな？（typeofも切実に( ゜д゜)ホスィ…）
P.S.3. Empty Base Optimization(EBO)もPolicy-baseな実装では重要なんですな．初めて気づいた．確かにスマポなんかじゃ至上命題な議論になるわ，そりゃ．
