Boost

複数の(異なり得る)型に対して効率的かつ安全な共通の戻り値型を計算する

複数の(異なるかも知れない)型のオブジェクトが単一の関数から返される場合を想定する. template< class T, class U > typename cradle::common_result< T const &, U const & >::type f( T const &t, U const &u, bool b ) { if( b ){ return t; } retur…

MSVC7.1 でもまだ SFINAE の実装は鬼門だよ,の実例

boost::transform_iterator の異なる instantiation 間の変換可能性の制御は SFINAE に基づく実装なんですぐわ, BOOST_MPL_ASSERT(( boost::is_convertible< boost::transform_iterator< int (*)( int ), std::vector< int >::iterator > , boost::transfor…

generic なオブジェクトの遅延構築に boost::optional が使えるんじゃないでしょ〜か

boost::optional *1ってドキュメントの Motivation で戻り値の型としての使用が挙げられているけれど, generic な文脈でオブジェクトの遅延構築――つまりオブジェクトを構築するストレージは確保しておくけれど,その初期化は遅延したい場合(構築しないまま…

Move Semantics があったら in-pace factory はほとんどいらない伊予柑いい予感

ほんとにどーでも良い些細なことだけれど, Move Semantics があったら in-place factory の存在意義が激減するよね,ってゆー.

flush on OutputFilter

恐らく flush は EOS の notification ではないし,そうあるべきではない?これから flush が実際問題として有効なインタフェースとして(エラー無しで)働くのは 1:n (n>=0) なストリーム上の変換に限られる?

close on Filter

close はストリームが終端に到達したこと(End Of Stream, EOS)を notify するために呼ばれる. Filter は Device の lifetime をコントロールしないし,させるべきではない. Filter の lifetime と Device の lifetime は独立であるべきで,これが有用と…

Blocking Monad

Blocking-Preserving の問題をもうちょい考える.そもそもある Filter が Blocking-Preserving であるとは,「その Filter に対する read/write の要求サイズに対して返される返答が要求サイズより小さくなるのは, Filter の下位にある Device が EOF に達…

TMP as "an intra-language glue language"

ところで全然話飛ぶけれど, Template Metaprogramming ってそれ単体で純粋に有用っつー場面はほとんどないっちぅか,コンパイル時計算ですよ, Turing Complete ですよ,だからナニ?例えば, 5! をコンパイル時に計算したいなら電卓で手計算でもして "hoge…

もにゃど的アダプタ

あ〜,くそぉっ!!もにゃど分かんねっ!!もにゃど分かんねっ!!もにゃど分かんねっ!!もにゃど分かんねっ!!もにゃどをちゃんと理解してて,あと関連するプログラミング言語・理論あたりについてきちんとサーベイすればある程度のとこに出しても恥ずか…

rule に対する operator| は短絡評価だよ

Boost.Spirit 使うたびにやらかす間違い.例えば以下のルールの定義では relational_operator は「絶対に "=" にマッチしない」. もう何回この間違いやらかしたことか…….最初の頃はこれにハマって,かつ脱出するのにとんでもない時間を食いましたが,今は…

関数呼び出し構文を AST で表現するときに root node はどーすりゃ良いのかにゃー問題

Boost.Spirit 使うたびにいっつもう〜う〜うなること.関数呼び出し式(より一般には postfix expression)を AST で表現するとき,何を関数呼び出し式に対する root node とするか.どうも以下のように関数呼び出し式の '(' (開きカッコ)にディレクティブ…

shared_ptr の作り方(副題:っていうかもはや吉野家コピペは時代の遺物?)

C++ 偏執狂の俺から言わせてもらえば今, C++ 偏執狂の間での最新流行はやっぱり, new すら書かない,書かせない(例えばここの "Generalizing the auto_ptr_new() Solution" の方法など),これだね。 new_( hoge, hage ); ( new_ てのはアトミックだから…

Generic Image Library (Boost candidate)

うひょっ!! (See also: http://opensource.adobe.com/gil/index.html) 前からそーだけれど,ここ最近は特に Adobe が C++ による実アプリよりの汎用ライブラリ設計・開発・運用・公開を企業レベルで行っている例の筆頭格を担ってるイメージが確実に出てき…

Descriptor/PropertyMap による抽象化

っていうか, PropertyMap についてもうちょっとちゃんと説明しておこうっと. 例えばグラフ構造を考えたとき,グラフの頂点と辺を表現するにあたって,実際に頂点クラスと辺クラスがあって……という抽象化は多分オブジェクト指向なデータ構造の抽象化では(…

PropertyMap

Iterator/Descriptor/PropertyMap による抽象化は非常に完成度が高く, Boost.Graph に限らず,汎用プログラミングの1つの高度な到達点だと思っていて,これによってとりあえずプログラムが走るようにデータ構造をでっち上げておいてから,後でデータ構造を…

なぜ condition::wait は lock 済みの lock オブジェクトを要求するのか?

Boost.Thread のインタフェース設計に関して疑問があったので,関連する議論を探してみたら発見. http://thread.gmane.org/gmane.comp.lib.boost.devel/75339/ boost::thread::condition::wait は渡される scoped_lock に対する事前条件として lock 済みで…

なぜ intrusive_ptr より shared_ptr をデフォルトとするべきか

http://thread.gmane.org/gmane.comp.lib.boost.devel/140434/ shared_ptr は, free store 上に参照カウント(と動的な削除子)を保持するオブジェクトを余分に必要とするので,基本的に(時間的・空間的)パフォーマンスとしては intrusive_ptr に劣る.な…

はじめてのぶぅすと☆すれっど

(実用レベルでの利用としては)はじめてのまるちすれっど☆ぷろぐらみんぎゅっ.そして必然的にはじめてのぶぅすと☆すれっど.えへへ.ないしょだよぉ? たった1箇所の mutable キーワードで single writer - multiple reader な仮定が破れちゃったりして(c…

Lambda/Closure in C++0x

http://www.tietew.jp/cppll/archive/12614 http://www.kmonos.net/wlog/59.php#_2335060328 ラムダ/クロージャの言語レベルサポートが 0x で実現するかというと,それはかなーり難しいのではないかというのがちょー個人的な予想. ラムダ/クロージャの言語…

Lambda@C++ の本質

C++ によるラムダ式エミュレートの中核は bind (引数束縛, partial application)ではないかと思った.ちぅか, bind をまず提供してそれの上に演算子関数のための関数オブジェクトクラスを構築すれば,かなり簡潔に Boost.Lambda 相当のものができるよ〜…

Boost.Build v2 (bjam) についていくつか

以下の話は全て Boost.Build v2 の話. v1 の話はしない.時間がないのでちょー箇条書き. 以下, Boost のソースツリーのルートを BOOST_ROOT と書く. bjam を動かすために bjam を動かすための設定方法はいくつかあるけれど 環境変数 BOOST_BUILD_PATH を…

ここまでコード

ということを思いついた.それだけ. #ちなみに上のコードは2時間ぐらいでちょーてけとーに組んだだけの,まともにテストもしてないものなので,何が起こってもわたしゃ知らん. #いちおーモチベーションとしては,複数のオブジェクト (コンテナや Range) …

Range の Source 化

#include <string> #include <vector> #include <algorithm> #include <ios> #include <iostream> #include <boost/mpl/bool.hpp> #include <boost/mpl/identity.hpp> #include <boost/type_traits/is_convertible.hpp> #include <boost/shared_ptr.hpp> #include <boost/utility/result_of.hpp> #include </boost/utility/result_of.hpp></boost/shared_ptr.hpp></boost/type_traits/is_convertible.hpp></boost/mpl/identity.hpp></boost/mpl/bool.hpp></iostream></ios></algorithm></vector></string>

arithmetic type / numeric type

言葉の定義のメモ. 符号付整数型 (signed integer types),(§3.9.1/2)で定義 signed char signed short int signed int signed long int (signed short int, signed int, signed long int は各々 short int (short), int, long int (long) という別名を…

値か,安全な参照か,素の参照か

値を持つか,他のオブジェクトへの参照を取るか,他のオブジェクトへの life time 管理付き参照を取るか,つーのを,生成の仕方で変更できるクラスってありかにゃ〜. // X への参照もしくは値を持つアダプタ class Adaptor { public: // 値を保持するのと等…

関数オブジェクトによる関数テンプレートのエミュレート

しかし死ぬほど忙しいのに,長文を.http://d.hatena.ne.jp/mb2sync/20060124#p1自分の場合,前々から汎用アルゴリズムを書く際はこの関数オブジェクトによる関数テンプレートのエミュレートで書いてきてたので,そのちんまい運用経験を元にいくつか書いてみ…

プリプロセッサ段階で MinGW を識別する

#include <boost/config.hpp> #if defined(__GNUC__) # if defined(BOOST_WINDOWS) // MinGW での GCC はここ # else // それ以外の GCC (Cygwin を含む) # endif</boost/config.hpp>

動的削除子 (dynamic deleter) - 意外と知られていない? boost::shared_ptr の側面

boost::shared_ptr は動的削除子 (dynamic deleter) と呼ばれる技法に基づいて実装されています.この動的削除子という技法で重要なのは, boost::shared_ptr が最終的に呼び出す解放処理が boost::shared_ptr のテンプレート引数の型に関係なく,コンストラ…

Type Erasure in boost::shared_ptr

そういえば,Type Erasureの一番顕著な実例が boost::shared_ptr っていうの書くの忘れてた. class C{}; boost::shared_ptr< void > p( new C ); // 参照カウントが 0 になるときちんと『C のポインタに対する』 delete を実行する別に void だけに限らず,…

friend 指定による限定的なインターフェース公開

上のをもうちょっと一般化すると, friend class 指定によって,限定した相手に,もしくは限定したセマンティクスでインターフェースを公開する手法・パターンとして確立できるような気がするけれどどうなんだろ?ちなみにこのパターンの他の例として, Boos…