先達のお言葉

http://lists.boost.org/MailArchives/boost/msg29087.php
当たり前のこと言ってるはずなんだけどこの人が言うと説得力が違う．

One observation to make is that efficiency is like friction: you never can take it back. This phenomenon is especially visible when abstractions that are built out of their concrete incarnations, are often less efficient when taken back to the same incarnations they started from. So an important thing to remember is, you can (at least theoretically) build a safe, highly abstract, and/or easy to use library, on top of an efficient one - but definitely not vice versa.

効率は一度失うと2度と戻らない・・・．自分が漠然と思っていたことを，はっきりとした言葉にしてくれるのは本当にありがたい．
ちなみに自分が最初にこのことを漠然と認識したのは，deallocateにsizeとして0を渡すと落ちるという現象に出会ったとき．このときに，libraryは0に対して安全ではないが効率は良い形で実装にしておいて，userの側で（必要があれば効率を犠牲にして）0でないことを保証させる仕様にしているんだろうと思った．しかし，逆にlibraryの側で0でないことを保証し，そのためにoverheadを払う実装であったとすれば，もはやuserにはどうすることもできない．ちなみに標準でdeallocateに0を渡したときの振る舞いについてどう書いているかは，今手元に規格書がないのでちょっと分からない．

Policy-based design (and similar techniques) tries to address this problem by giving some structure to the design space, but letting the user make the move. So instead of a point, the library offers multiple reachable points in the design space, and furthermore the user can define new points within certain limited directions. This way, the library does give reuse benefits, while letting the user call the shots.

この部分は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な実装では重要なんですな．初めて気づいた．確かにスマポなんかじゃ至上命題な議論になるわ，そりゃ．