■

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 だから採用されて無いけれど) ．

■

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

■

もうなんかかれこれ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 されるるるぅ．