ようやく関数の定義の仕方が分かってきたのでまとめておこう Iterator AdaptorのためにFunctionObjectはできるだけDefaultConstructibleかつAssignableにしておいた方がいい この不具合の回避策がかなり正確に分かった 基底クラスを持つか、あるいはユーザ定…

関数オブジェクトfooと、その型op::foo(cv-qualifierなし)があるとする result_ofにはop::fooを渡すことになる (op::fooの参照型を渡してはいけないと思われる 20.5.4/1) 厳密には、result_ofだと思うのだが、constは付けないらしい (参照) 関数テンプレート…

開発中のBoost.Protoを使って演算子のオーバーロードをしてみる (実装) result_ofにはまだちゃんと対応してないようだ 以前の使い方([id:mb2sync:20051025])とは、かなり変わっている []#include[] []<pstade/oven/compile.hpp>[]</pstade/oven/compile.hpp>

型がMetafunctionであるかないかでapplyの動作が変わる PlaceholderExpression自体がill-formedになり得る 型でないパラメータを取る場合機能しない デフォルトでは、template parameterの数が５個より多いと動作しない boost::tupleなんかは駄目である GCC3…

テンプレートを利用した型はコンマで区切られていることがあるので([id:Cryolite:20050326])を使うのだが、const修飾が消える (13.1/3) VC++7.1は消えないので注意 コンマを保護するマクロを呼ぶのはユーザの責任になる こうすればどうだろう (実装) affect…

引数は5個まで (実装) 試しに10個にするとコンパイル時間が大変なことになった これもただの実験コードというわけではなく、 Boost.Lambda functorを一時オブジェクトを実引数に取れるように変換できる lambda::ret<>に相当する機能を付けられる 関数オブジ…

前回([id:mb2sync:20061210])のはマクロになってしまったが、マクロなしでもできた (実装) []#include[] []<utility>[] []#include[] []<pstade/object_generator.hpp>[]</pstade/object_generator.hpp></utility>

make_pairなどのコードは大体似通っている 自動化してしまえ (実装) 結局マクロになってしまった []#include[] []<utility>[] []#include[] []<pstade/object_generator.hpp>[] []#include[] []<boost/tuple/tuple.hpp>[]</boost/tuple/tuple.hpp></pstade/object_generator.hpp></utility>

オリジナルのcallableにresult_ofのサポートをつけると、偶然にも？そのままこの回避策になってちゃんとVCでも動く！ 実装とサンプル これで関数との戦いは終わった

tupleを取る関数を普通の関数に変換する (実装)と(サンプル) これはただ面白いというだけではなく、「まずTupleを引数にとる関数を実装しておいて、それをuntupledに変換してユーザに提供する」という方法でプリプロセッサを使わなくてよくなる はずなのだが…

関数呼び出しのシンタックスは醜い Range Library Proposalではoperator|を使った回避策が提案されている これはRangeに限った話ではないので、result_ofを使って書こう (実装) []#include[] []<boost/utility/result_of.hpp>[] []#include[] []<pstade/pipable.hpp>[]</pstade/pipable.hpp></boost/utility/result_of.hpp>

今度こそ完成した、はず (ドキュメント) こういうものを作ると、これらのクラスは使ってはいけないとよく分かる！ ただCSimpleArrayと文字列クラスは役に立つかもしれない ついでにWTLも サンプルコード