■

もうなんかかれこれ2ヶ月ぐらい SBPP 読破するつもりでいたけれど読んでも読んでもまったく頭に入らないので， TDD 読み始めたけれどやっぱりまったく頭に入ってこないいいぃぃぃ．っていうか Kent Beck の英語読みにくい……いや，英語読みにくいだけじゃないんだけれど……．なんだろう？まったく読めてない感が．仕方なくこの2冊をほっぽりだして POSA の Vol.1 をちゃんと読み始める．
このままでは TCP/IP Illustrated (ぼｗっｗくｗすｗせｗっｗとｗ) → UNIX Network Programming (多分ここで Advanced Programming in UNIX Environment が入る． Richard Stevens 的に考えて) → Boost.ASIO で遊ぶ，という予定がどんどん postponed されるるるぅ．

■

そういえば，ある汎用アルゴリズム (関数テンプレート) の実装が与えられたときに，その汎用アルゴリズムの requirement 項に関する推論機構が欲しいと誰かが (俺かぁ！) ほざいてた気がするけれど， requirement に記述した制約 (インタフェイス) のみを使って汎用アルゴリズムが記述されているかを point of definition で検査するという concept の側面 (archetype test) も重要で (みんな point of instantiation における間違った使い方でエラーがでれでれーって出てくるのをなんとかしてくれ！っていう側面ばかりに気を取られていることが多いけれど)， requirement を推論するとこの検査機構が形無しになるよなーとか思いつつえーと……なんだっけ？忘れた．

■

O(1) か O(log N) かよりも leading coefficient の大小のほうが実用的には重要だったりするかも知れない昨今，皆様いかがお過ごしでしょうか？それはさておきまして誰か splice の使い方を列挙しまくって std::list の不憫な立場をなんとかしてやってくだしあ！
＃splice をガンガン活用しようとすると in-place insert か move semantics が欲しくにゃるにゃー．
＃singly linked list の proposal がおおまか accept されたってことは， node-based sequence にはそれなりになんか使い道があるんでしょう．あるんでしょう？てか，ノード1つあたりポインタ1個分の変更のコストも惜しいドメインってどんなんなんだろー？どうでも良いけれど，従来の slist における insert/erase (before) が単純には O(N) かかりますけれどどうするんでしょう？周り (これが slist が std 入りから漏れた最大の理由たる争点だと思うけれど) に対して，この article に書かれている design space の考察が「なるほどにゃーなるほどにゃー」ですっていうか， insert/erase が O(1) になる実装として， iterator の dereference の結果をノード1個分ずらすっていうアイデアあたりは初めて知って目からわぴこが落ちた (efficiency という motivation から singly linked list が欲しいのに対して，この実装は efficiency の観点からは損なので， motivation と inconsistent だから採用されて無いけれど) ．

concept via type class

Haskell に type class が導入されている motivation についてまとまってるサイトにゃいかにゃー． Haskell の type class を通して C++ の concept を見てみたいの会．あと， C++0x の concept で functional dependency が手軽に扱えそうか/有用そうかどうか誰かおすえてっ！＜functional dependency がいったい何なのかさっぱり理解していないが，とりあえず面白そうだから見てみたいというバーカバーカ

concept-based overload の使い道はそれこそいくらでも……

http://d.hatena.ne.jp/NyaRuRu/20080328/p1
(C++[0x] の言葉でいうところの) concept-based overload と，関数テンプレートの partial ordering が混ざった話だけれど， concept-based overload に関しては
＞まあ使い道がそんなに沢山あるかというとそこはよく分かりませんが
使い道なんて山ほどあるよっ！！！＜書いちゃった書いちゃった！
これこそまさに C++ のコミュニティが欲しい欲しいと言い続けてきたもの (の一部) ですし，多分 C++ コミュニティのエライ人に聞いたら，いくらでも使い道はでれれれれーって出てくるような希ガス． C++0x に入れられようとしているものはこれ ("これ"っつっても C# の extension method あまり詳しく知らないんだけれど) より3回りほど (structual, scoped, non-intrusive) えげつない気もするけれど……いかんせんまだちゃんとした実装がにゃいからにゃー．結局，現状の C++ では「山ほどあるよっ！！！」で終わってしまうー．

Re: std::reference_closure の存在意義

昨日のk.inabaさんのコメントにいったん納得しかけたけれど

void funcWithCallback(std::reference_closure<int(int)> const &f); // 定義は別のバイナリにある

void g()
{
  int i = 42;
  funcWithCallback([&](int j){ return i * j; });
}

これが std::reference_closure の目的なら，普通の関数ポインタから std::reference_closure への変換について何にも言及されていないのがやっぱり納得いかねー．
一方で，これが std::reference_closure の目的なら

その一方で、reference_closureは仮想関数を持たないので、クロージャオブジェクトの型Fをreference_closureから派生させることの必要性は感じません。 唯一の利点は、暗黙的にreference_closureへ変換できることでしょう。

この，参照経由でのみ環境にアクセスするクロージャオブジェクトの型 F だけを std::reference_closure から派生させるというのは理解できるというか，むしろ「reference_closure への暗黙の変換が欲しい．」暗黙の変換を可能にする機構としては別に継承以外にもたとえば変換コンストラクタテンプレートがありますけれど，これだとすべてのクロージャオブジェクトからの変換を許してしまう．「参照経由でのみ環境にアクセスするクロージャオブジェクトからのみ選択的に std::reference_closure への変換を許す」を C++ の言語機能で表現した結果，「参照経由でのみ環境にアクセスするクロージャオブジェクトのみ std::reference_closure から派生する」って表現になったんじゃないかにゃー，ってゆ〜．

"Design Patterns in C++," articles in TopCoder

http://www.topcoder.com/tc?module=Static&d1=features&d2=100206
http://www.topcoder.com/tc?module=Static&d1=features&d2=100906
これは良い article．ただ， "non-intrusive" とか "type erasure" とかいう keyword を含んだ article なら，どんな article だろうが「良い article」って言い出す勢いじゃないかっていう……．この article って，ある程度のベースの知識があって初めて「うんうん．これは良い article」って言えるような代物であって， introductory な意味では良い article じゃない．どちらかというと不親切な article．っていうか，この手の，現代的な C++ generic programming に関する article で親切なものって見たことないけれど．