前に同じ題を出しましたが，今回はまた別で．舞台はやっぱりBoostですがｗ．
http://page.freett.com/shelarcy/diary2002-6.html
ここから情報をキャッチ．若干古い議論ですが以下が元．
http://lists.boost.org/MailArchives/boost/msg29015.php
ミーハーな私は投稿者の名前だけですでに「A. Alexキタ━━━━━━ヽ(≧∇≦)ノ━━━━━━!!!!!」な状態になっちゃうんですがｗ．もとい，std::auto_ptrとboost::scoped_ptrなんてぶっちゃけownershipの扱い方の違いだけなのに，なんでわざわざ名前変えて（そしてその実装はほとんど同じなのに）別口で提供する必要があるのか？とか言うあたりは確かに自分も疑問に思っていました．
自分の実経験ではスマポにぬるぽ（ガッ！！）が入らないことが前提として立てられるのに，ライブラリ内のその実装詳細をクライアントである自分の側からいじる機構がなくて，ぬるぽ（ガッ！！）チェックのoverloadを支払うのは，特にpointerのようなprimitiveなものにおいては気になる，なんてことがありました．このレベルの違いはさすがにpolicyとして切り出すのが得策かとは思うのですが，どうなんでしょ？
ここでA. Alexが述べているODRとの絡みも「確かに言われるとおりだ」と思います．が，かといって全部Policyでクライアントに決めさせるのもなんだかなぁとは思います．もちろん，ライブラリ提供者はデフォルトを提供できますし，名前付きテンプレート引数なんて便利なものもありますから，クライアントがより楽な形でいじれるようにはできるとは思いますが．ここでの自分の疑問は単純に「template引数が10個もあるようなクラス作って正直どうするんだ？」っていうものなんですがｗ．いや，自分が憧れる世界ではあるんですが・・・・あるんですが・・・ねぇ？ｗ
スマポなんていう単純な例をとってみても（というか単純な例ほどこういうtemplatized policyが要求されるんだとは思いますが），pointer typeに始まってownership，ref-count, null-po(hit!!) check, thread policy, exception plicy, extrusive（intrusiveの対義語のつもりｗ）/intrusive, weak/strongと腐るほどありますねぇ．．．．「正直こんなの作ってどうするんだ？」って漠然とした疑問が湧きませんか？ｗこういうのを見るとTraitを支持する側の主張も追っていく必要がありそうですが．．．．う〜む，スマポなんてMore Effectiveに載っているぐらいの知識で満足しておけばよかった．．．．もうこの泥沼（褒め言葉ですよ？ｗ）から足を抜け出せない．
P.S. 最近A. Alexはどうしているんでしょうねぇ・・・
P.S.2. STLも使っていると古臭さを感じさせる部分がだいぶ出てきてますよねぇ．Policy-basedなSTL書こうって言う粋な変態さん（褒め言葉！）はいらっしゃらないんでしょうか？mapに対しては以前にBoostのMLで議論がありましたが・・・正直追えてないｗ．（ちうか月1000通の英語のそれも最先端に近い議論を延々やってるMLを「あくまで趣味として」追うのがそもそも無理なわけでしてｗ．)
P.S.3. 紹介した投稿の最後のほうで，interfaceに関してもtemplateで提供することを考え直しているようですが，正直あれはやりすぎのような（汗．MC++Dで最初に見たときは確かに「うへぇ・・・」と思ったんですが，あまりにも危険というか土台のクラス（Policyでいじられるクラス）が，もはや何を規定しているのか分からなくなるｗ．まぁ，interfaceにこだわるのはOOの考えを捨て切れていないからかも知れませんがｗ．クラスが規定するのはもはやアルゴリズムだけ？そういや昨日，comp.langのほうでchained inheritanceなんてのも発見したなぁ．
