動的削除子 (dynamic deleter) - 意外と知られていない？ boost::shared_ptr の側面 - Cry’s Diary
boost::shared_ptr は動的削除子 (dynamic deleter) と呼ばれる技法に基づいて実装されています．この動的削除子という技法で重要なのは， boost::shared_ptr が最終的に呼び出す解放処理が boost::shared_ptr のテンプレート引数の型に関係なく，コンストラクタに実際に渡されたポインタの型で，かつ boost::shared_ptr のコンストラクタの呼び出しの段階で 決定する，ということです． 以下のようなコードが，動的削除子の効果が一番分かりやすい例になるでしょう． class X{ public: ~X() { std::cout << "X::~X" << std::endl; } }; class B{ public: ~B() // virtual でないことに注意！！ { std::cout << "B::~B" <<
2008-02-02 - Cry’s Diary : [C++0x][C++]可変長テンプレートの使い道が「型安全な printf」と「tuple」と「転送関数 (関数オブジェクト)」ぐらいだと思っている人へ送る，ちょっと早めの素敵な variadic
N2461 より "12.6.2 Initializing bases and members" の 10 の例示コード． template<class... Mixins> class X : public Mixins... { public: X(const Mixins&... mixins) : Mixins(mixins)... { } }; 同じく N2461 より "14.5.3 Variadic templates" の 5 における例示コード． template<typename...> struct Tuple {}; template<typename T1, typename T2> struct Pair {}; template<class ... Args1> struct zip { template<class ... Args2> struct wit
![2008-02-02 - Cry’s Diary : [C++0x][C++]可変長テンプレートの使い道が「型安全な printf」と「tuple」と「転送関数 (関数オブジェクト)」ぐらいだと思っている人へ送る，ちょっと早めの素敵な variadic](https://cdn-ak-scissors.b.st-hatena.com/image/square/7ab80b5c1457792cf3483507f743d05b574c06e4/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F8454420450097600593%2F10257846132638279677%2F1537749466)
(私が C++ プログラマだということに一応の合意をしていただけると仮定した上で) ある C++ プログラマから見た Garbage Collection の理解 - Cry's Blog
少なくとも自分は， C++ でプログラムを組むなら，生成したオブジェクトは必ず責任を持って破壊することを徹底しているし，確保したヒープは責任を持って OS さんにお返しすることを徹底している．これは C++ の基本中の基本だというのが自分の考え．だから C++ においては「他のオブジェクトから参照されなくなった不要なオブジェクト (ゴミ，garbage) を回収 (collection) する機構」は要らないというのが個人的な立場． しかしながら，「だから C++ において GC は不要」とはならない．これが今現在の自分の考え． C++ には，他のオブジェクトを参照するという概念を言語の機能として提供していて，それは型・構文に明示的に現れる．ポインタ型・参照型がそれ． 注意するべきは， C++ においては「あるオブジェクトを参照している」という概念と「あるオブジェクトの生存を維持している
例外処理@C++ - Cry's Blog
C++ に限定して言えば， 例外処理とは，究極的には「いかに try-catch を書かずに済ませるか」 だと思っている人だったり．要するに，例外処理という文脈においても RAII の徹底というのが C++ としての基本だろう，っていう．ただし，あくまで「究極的には」であって，たった1つの関数だけで必要となる特殊な rollback 処理に対して，いちいち対応するクラス定義を切り出すことが実用上無理なのは確か．その「実用上 RAII で扱うのが難しい部分」を救う言語機能は欲しいけれど，それは GC でも finally でもないと思うにゃー，っていうのが今現在の自分の考え． 「GC は例外使うときに便利」というのは，確かにその主張は真だと思う一方で，あまりにも「便利になる範囲が狭すぎる」嫌いを感じる． finally に関しては以下に書くかも知れにゃい．
ConceptGCC で遊びましょ♪ - Cry's Blog
っつーか， C++0x で遊び倒すなら ConceptGCC の方がえーんちゃうん？ってゆー． SVN リポジトリのヤツだと concept 他， decltype, rvalue reference, variadic templates がすでに merge されててえらいことになってるし (参考)． x86-64 だとコンパイルこけるっぽいけれど，まー x86 で遊べたら十分だし． ただ，イマイチ安定していなくてコーディングする際に試行錯誤しないといけないのが難点だにゃー．あと， concept のチェックがシビアだからそれも比較的しんどい． late_check で逃げることはできるんだけれど．
scanl で作る自然対数への (無限) 遅延リスト in C++ - Cry's Blog
scanl 相当を実装したので適当に遊んでみるテスト． http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/*checkout*/cradle/cradle/libs/range/test/integration/lazy_list_to_exp_utf.cpp?content-type=text%2Fplain MSVC7.1, 8.0, GCC4.0.x, 4.1.x でテスト済み．余計なものごちゃごちゃくっついているので分かりにくいですけれど，中核となっているのは range::assign( range::iterating( as_pure( _1 + 1.0 ), 1.0 ) | range::view::transform( as_pure( 1.0 / _1 ) ) | range::view::scan_left( as_pure(
Wanted: Gamma Function - Cry's Blog
っていうか， C++ 標準だとガンマ関数を計算するための関数が無いのではないかという恐ろしい事実に今気が付いた．TR1 にすら無いっ！ TR1 でベータ関数云々導入されてるけれど，それ以前にまずガンマ関数はっ！？ねぇ，ガンマ関数はっ！？ C99 にはあるんだけれどねぇ． こうなると自作するしかないんだけれど，っていうかガンマ関数を求める精度で近似する方法誰か教えてぇ〜． Stirling の公式のもっと高次項まで展開したヤツ (ポアンカレの漸近展開) を使うっつーので良いのですかね？っていうか久しぶりに特殊函数の本引っ張り出してくる羽目になったんですけどっ！？っていうかこんなことに拘泥されている暇はないのだだだっ！うはー超幾何函数とかなっつかすぃーーー……いやそうじゃなくてっ！！ がでかい場合 0verflow するので (でかいといってもガンマ関数自体階乗の速度で増加するのでが2桁か3桁
所有権 - ownership - Cry's Blog
所有権 ownership という言葉は， C++ においてほぼ最重要と言っても良いほど重要な概念だと思うけれど，この言葉を完全に前面に押し出して説明している書籍なりウェブページなりを見た記憶がほとんどない． 自分が考える C++ らしいプログラミングのためのまさに第一歩は，この所有権の概念の獲得だとまで思うんだけれど，それにしてはこの言葉が語られる機会があまりに少ない気がする． 所有する権利というのは，開放する責任と完全に表裏一体のものなので，所有権の概念の獲得は，即， RAII という発想に自然に展開される．ただ，ここで言ってる所有権はかなり漠然としたもので，ここで言ってる RAII というのも "Resource Acquisition Is Initialization" という言葉の直接的な意味よりもかなり拡大されたもの．マウスカーソルを砂時計付のカーソルに変える操作をコンストラ
複数の（異なり得る）型に対して効率的かつ安全な共通の戻り値型を計算する - Cry's Blog
複数の（異なるかも知れない）型のオブジェクトが単一の関数から返される場合を想定する． 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; } return u; }このとき，上のコード片におけるメタ関数 cradle::common_result の設計と実装を行いたい，という問題． まず，標準の規格 ISO/IEC-14882:2003 にある記述で問題領域をほぼ共有するものがあるのでそれを参考にする．（3項）条件演算子の戻り値の型に関する記述 (5.16/3), (5.16/4), (5.16/5), (5.16/6) がそれ．ちゃんとこれを説明す
generic なオブジェクトの遅延構築に boost::optional が使えるんじゃないでしょ〜か - Cry's Blog
boost::optional *1ってドキュメントの Motivation で戻り値の型としての使用が挙げられているけれど， generic な文脈でオブジェクトの遅延構築――つまりオブジェクトを構築するストレージは確保しておくけれど，その初期化は遅延したい場合（構築しないまま終わる可能性も含む）――を行うためのラッパとしても十分機能するよにゃ〜，とか思っていたらドキュメントの Example のところにほぼそのまんまの例（Optional local variables, Optional data members）があるじゃん．ずががががーん． Motivation のところしか読んでなかったから気づかなかった……． 汎用な文脈でオブジェクトの遅延構築がなぜ難しいかというと， ストレージの alignment に気を使わないといけない ストレージに実際のオブジェクトを構築する部分で例
TMP as "an intra-language glue language"
ところで全然話飛ぶけれど， Template Metaprogramming ってそれ単体で純粋に有用っつー場面はほとんどないっちぅか，コンパイル時計算ですよ， Turing Complete ですよ，だからナニ？例えば， 5! をコンパイル時に計算したいなら電卓で手計算でもして "hoge = 120; // 5!" とかコメントに注釈でも書いておきなさいよ，とか半ば本気で思っている人で……っていうか， TMP 単体は基本的に非常に実装コストが高く，効率も非常に悪く（ここで言ってる「効率」とはつまりコンパイルにかかる時間とコンパイル時に消費されるメモリに関する効率），文法に関しても洗練のせの字もないという言語なので， TMP でフィボナッチとかたらいまわしとかカックロ電卓とか C++ コンパイラで計算しましたとかってマジで趣味としての楽しみと自己満足と TMP に馴染む時間以外のなんらの
もにゃど的アダプタ - Cry's Blog
あ〜，くそぉっ！！もにゃど分かんねっ！！もにゃど分かんねっ！！もにゃど分かんねっ！！もにゃど分かんねっ！！もにゃどをちゃんと理解してて，あと関連するプログラミング言語・理論あたりについてきちんとサーベイすればある程度のとこに出しても恥ずかしくないレベルの何かに仕上げられる気がするのにっ！！のにっ！！ 合成可能なアダプタ，あるいはそれに類似の概念は何らかの汎用な形に formalize できる．既存の C++ のライブラリ実装で体現している具体例としては Boost.Lambda, Boost.Iterator の Iterator アダプタ群, RangeEX のアダプタ群, Boost.Iostreams （の Filter）など．あと個人的に思いつく範囲としては PropertyMap に対するアダプタ，他 GUI など Decorater パタンが適用できる領域， Proxy パタン
もにゃど - Cry's Blog
これぐらいなら FC++ あたりを漁ればあるような気がする．っていうかもにゃど分かんね．そこらへんに落ちてた解説をてけとーに読んだ結果，「合成演算に何かを引っ掛ける」ぐらいにしか理解できていない．手続き脳の限界．っていうか手続きで書ける言語にもにゃどがあってうれしいことってあるんでしょうかね． ＃うれしい気がしてきた．でもねもい ＃あ，下のコード無駄に stdexcept インクルードしてるし．これプラス F の次が G じゃなくて H なところから推論される結論は……「error monad も作ろうとしてたけど何となく途中でやめてしまった」． #include <iostream> #include <stdexcept> #include <boost/optional.hpp> #include <boost/utility/result_of.hpp> namespace may
2万円の違い - Cry's Blog
以前，秋葉原のどこかの PC ショップに寄ったときに，店内に HHK の Lite2 と Professional が並べておいてあって，そのときにキータッチを比べたことがある．そのときは違いが全然分からなかった．なんでこんなものに2万近い差額を払うのか全く理解できず，結局それ以来 Lite2 を使い続けていた． しかし最近ひょんなことから Professional が手に入ったのでしばらく使いこんでいた．2週間くらい Professional を使い込んでの感想． 「なんで2万くらいの差額を惜しんでいたのか全く理解できない．」 人間ぜーたくに慣れるといかんですねー．ノート PC 用として持ち運ぶためにもう1台欲しくなってきちゃいましたよよよ？
Descriptor/PropertyMap による抽象化 - Cry's Blog
っていうか， PropertyMap についてもうちょっとちゃんと説明しておこうっと． 例えばグラフ構造を考えたとき，グラフの頂点と辺を表現するにあたって，実際に頂点クラスと辺クラスがあって……という抽象化は多分オブジェクト指向なデータ構造の抽象化では（発想としては）一番自然かもしれないけれど，一般には様々なトレードオフなどからこのタイプの抽象化が許容できない場合も多い．例えば，最も代表的なグラフ構造の抽象化の1つである隣接リスト表現を考えても，頂点はプログラム上での明示的なオブジェクトとして表現されていない． もう一つ重要な点は，グラフを扱う側（ユーザ側）ではグラフ構造がどういう抽象化をされているかなんてぶっちゃけどーでも良くて，（実際に頂点や辺がプログラム上で明示的な頂点オブジェクトあるいは辺オブジェクトとして表現されているかどうかに関係なく）あるグラフ内の「ある頂点を一意に表すナニカ
型に対する const 修飾が read に関するスレッド安全を含意する，という性質 - Cry's Blog
ある型 T があって， T のオブジェクトが const 修飾されているならば，そのオブジェクトに対する(const_cast をはじめとする const 性除去の構文を除く)あらゆる有効式がそのオブジェクトに関してスレッドセーフである，っつー性質を考える． この性質は，言い換えると，あるスレッドが const 修飾された T のオブジェクト，もしくはそれへの参照・ポインタを持っていた場合，そのスレッドはどう頑張ってもそのオブジェクト，もしくはそのオブジェクトが直接・間接に参照するオブジェクトに対する (Readers/Writer Lock の文脈でいうところの) Reader にしかなれない，というもの． この性質は，さらに言い換えると， T に対する const 修飾が単に論理的な定数性だけではなくて厳密にビット列の定数性を保証する，というもの． C++ では，オブジェクトに対する
Cry’s Diary - shared_ptr の作り方（副題：っていうかもはや吉野家コピペは時代の遺物？）
C++ 偏執狂の俺から言わせてもらえば今， C++ 偏執狂の間での最新流行はやっぱり， new すら書かない，書かせない（例えばここの "Generalizing the auto_ptr_new() Solution" の方法など），これだね。 new_< MyClass >( hoge, hage ); （<- new じゃなくてアンダーバーが付いた new_ ね）これが偏執狂の shared_ptr (auto_ptr) の作り方． new_ てのはアトミックだから，ここに書いてあるような， new を生で使った場合に例外安全じゃないっつー状況に対するフェイルセイフが多めに入ってる． その上， shared_ptr< MyBase >( new MyClass( hoge, hage ) ); に比べてコード量が少なめ．これ． で，この議論は一般にファクトリ関数全般に適用できて，さら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
■ - Cry's Blog
Lanczos approximation - ガンマ関数の数値計算 - Cry's Blog