Double dispatch がめんどくさい

2013-09-04T00:29:59+09:00

* Double dispatch がめんどくさい #right{last update: &update(format=Y/m/d (D))} ヤブから棒ではあるが， Rectangle rectangle; Circle circle; PenSVG pen_svg; PenPNG pen_png; rectangle.drawWith(pen_svg); circle.drawWith(pen_svg); rectangle.drawWith(pen_png); circle.drawWith(pen_png); …というようなことがしたい．要は四角形とか円とか，ひょっとしたら楕円とか菱形とかいろんな図形があって， PNG とか SVG とか，ひょっとしたら JPEG とかに出力するペンがあって，どの図形も，どのペンでも自在に組み合わせて描きたい，という意味である． ** その１簡単にプログラムを書くとこんな感じ． // Shape.hpp class PenToPNG; class PenToSVG; class Rectangle { public: void drawWith(PenToPNG & pen); void drawWith(PenToSVG & pen); }; class Circle { public: void drawWith(PenToPNG & pen); void drawWith(PenToSVG & pen); }; // Shape.cpp #include "Shape.hpp" #include "Pen.hpp" #include void Rectangle::drawWith(PenToPNG & pen) { std::cout << "Rectangle: PNG" << std::endl; } void Rectangle::drawWith(PenT

続続無限リスト

2012-12-11T22:46:34+09:00

*続続無限リスト #right{last update: &update(format=Y/m/d (D))} [[前回>続無限リスト]]，C++0x の新機能である lambda 式を活用し，関数型言語における list を構築した．今回はまず，このクラスを使っていろいろなプログラムを書いてみる．まず，list の空判定と出力を実装する． template class list { // 省略 // リストが空であるかどうか bool is_null() const { return !_cell; } }; // 出力 // #include template std::ostream & operator << (std::ostream & stream, list const & xs) { return xs.is_null() ? stream << "()" : stream << "(" << xs.car() << " , " << std::flush << xs.cdr() << ")"; } 次に，いくつかのリスト操作関数を実装する． template class list { // 省略 // xs.take(n) で xs の先頭 n 要素を切り出す． list take(unsigned int n) const { list xs = *this; return n == 0 ? list() : list(car(), [n, xs](){ return xs.cdr(), take(n - 1); }); } // xs.zipWith(f, ys) で f(x, y) のリストを計算. template list

続無限リスト

2012-12-08T05:27:51+09:00

*続無限リスト #right{last update: &update(format=Y/m/d (D))} [[前回>無限リスト]]，C++0x を用いて基本的な無限リストを作成した．とはいえ，目につく問題も残っていた．例えばリストを扱うために常に shared_ptr を経由しなければならなかったり，リストの 2 番目を参照するために ls->cdr()->car といった不自然なメソッド呼び出しをする必要があったりした．これを改善しよう．まず，常に shared_ptr となるのを防ぐには，cons セル全体をラッパクラスで覆えばよい．例えば以下のようになる． template class list { struct cell { T _car; std::function()> _cdr; cell(T const & car, std::function()> const & cdr) : _car(car), _cdr(cdr) {} }; std::shared_ptr _cell; }; std::list と名前が衝突する？そんなことは using namespace std する奴が悪いのだ（おい）それよりも問題は，この list をどうやって構築するかである．前回は cell 構造体そのものを lambda 式を用いて直接構築した．しかし今回は cell 構造体は private なので外部からは隠蔽されている．なので nat_from で「std::shared_ptr を返す lambda 式」を直接生成できない．そこで，ユーザ側では「list を返す lambda 式」を定義してもらって，それを「std::shared_ptr を返す lambda 式」に変換してやる必要がある．この変換をコンストラクタとして実装してやればよい．ついでに，C++0x らしく cell 構造体

無限リスト

2012-12-06T02:57:05+09:00

*無限リスト #right{last update: &update(format=Y/m/d (D))} Scheme や Haskell などの関数型言語では，無限の長さのリストを自然に扱うことができる．例えば Haskell では nat_from :: Int -> [Int] nat_from x = x : nat_from (x + 1) という関数を定義すると， nat_from 1 で [1, 2, 3, ...] という無限リストを生成できる．ちゃんと head (nat_from 1) で 1 が返るし，head (tail (nat_from 1)) では 2 が返る．無限ループに陥ったりはしない．同じ事を scheme でやろうとすると (define-syntax lazy-cons (syntax-rules () ((_ x y) (cons x (delay y))))) というマクロを用意し (define nat-from (lambda (x) (lazy-cons x (nat-from (+ x 1))))) (nat-from 1) と書くことになる．lazy-cons を使わなければならなかったのは，haskell が何もしなくても遅延評価なのに対し，scheme は delay/force 機構を用いなければ遅延評価されないからである．もしこれを (define nat-from (lambda (x) (cons x (nat-from (+ x 1))))) としてしまうと，例えば (car (nat-from 1)) を評価しようとしても，先に (nat-from 1) を先に完全に構築しようとして無限ループに陥ってしまう．このように，無限リストを扱うためには遅延評価が必要になる．逆に，遅延評価（と再帰関数）が使えるなら，そのプログラミング言語では無限リストが扱える．で，C++0x の情報を眺めていたら，lambda 式が追加されているのに気がついた（遅い）．lambda 式とは局所的に関数を生成する式のことで，例えば int 型同士の足し算を表す lambda 式は [](int x,

C++ × 定理証明

2012-09-09T01:47:59+09:00

* C++ × 定理証明 #right{last update: &update(format=Y/m/d (D))} 世の中には酔狂な人がいるもので，プログラミングと定理の証明が等価だと言った人がいるそうな．これを「カリー・ハワード対応」と言うらしい．カリー・ハワードさんが言ったのか，カリーさんとハワードさんが共同で発表したのか，カリーさんとハワードさんが独立に発見したけどたまたま時期が同じだったのか，詳しいことは知らないので調べておくように．で，気になった．我等が C++ も定理証明と等価なのだろうか．等価だとしたら，我々がプログラムを作るとき，それはどのような定理を証明していることになるのだろうか．やってみる．まず，定理証明といったとき，これは論理学で言う形式的証明のことである．形式的証明にはいくつかの流儀があるが，そのうちの１つにヒルベルト流の形式化というのがある．ヒルベルト流の形式化では，全ての命題を「A ならば B」（これを「含意」と言う）と「A でない」（これを「否定」と言う）で表す．これを以下のように書こう． A -> B // A ならば B !A // A でないさて，これに対応する C++ プログラムを考える．カリー・ハワード対応では，命題は型と対応する．「含意」は A という型と B という型から新たな型「A -> B」を作り出す操作となる．これは C++ では template で実装できる．同様に「否定」も template で実装できる． template struct then {}; template struct negate {}; 「ならば」は英語で「then」である．「A ならば B」は英語で「A then B」であり，C++言語で「then」である．「でない」は英語で「not」だが，not は識別子としていろいろ問題があるので「negate」を使った．次に，ヒルベルト流の定式化では，推論規則として「A -> B であり，かつ A ならば B」を用いる．俗に言う（正しくは言わない）３段論法，ちょっとかっこよく言うと「モーダスポネンス」である．ちなみに推論規則

コメントログ

2010-12-29T03:35:18+09:00

- コメントの投稿テスト -- (tossy_squirrel) &size(80%){2010-12-29 03:35:18}

singleton × thread

2010-12-28T17:25:22+09:00

* singleton × thread #right{last update: &update(format=Y/m/d (D))} さて，この記事のテーマとは singleton と thread でどちらが攻めでどちらが○けか，''ではない！'' なんてタイトルをつけやがる…．期待させて申し訳ないが（ありえない） Singleton とは，プログラム内でインスタンスが 1 つしか存在しないことを保証するクラスのこと．要はグローバル変数の代わり．簡単なコードは以下の通り． // singleton.h #include #include class Singleton { private: Singleton() { std::cout << "Singleton : created" << std::endl; } Singleton(const Singleton&); // コピー禁止 Singleton& operator=(const Singleton&); // 代入禁止 public: ~Singleton() { std::cout << "Singleton : deleted" << std::endl; } // インスタンス取得関数 static Singleton* getInstance(); }; // singleton.cpp #include "singleton.h" Singleton* Singleton::getInstance() { static Singleton instance; return &instance; } さてここで疑問に思った．このインスタンス取得関数ってマルチスレッド安全なの？調べると，「C では静的自動変数の初期化は，実行フローが最初に変数の宣言・初期化行を通過した時に行われる」とある．ならば Singleton のコンストラクタが何やら時間のかか

続続続 template × mix-in

2010-12-28T18:31:33+09:00

* 続続続 template × mix-in #right{last update: &update(format=Y/m/d (D))} さて， [[前回>続続 template × mix-in]] でテンプレートを用いた Mix-in についてはほぼカタがついたはずだ．なに？ソースが長い？　Mix-in を定義するたびに IMix だの Mix だのを定義するのがめんどい？　なんとかならんのか，だって？というわけで，なんとかしてみる^^． ** その６まず， template を使ったテクニックではある程度長くなるのは仕方がない．というか，前回のコードでも裏で結構頑張って短くしているのだ．なので，これを越えるためにはいろいろと禁断の秘儀^^を用いる必要がある．こういう場面で C のプログラマが真っ先に思いつくのはプリプロセッサマクロだろう．私もそう思う．だが，今回のコードを展開するマクロを作るには，マクロが Mix-in するメソッド名のリスト（add と remove）を取り扱える必要がある．そこでまたまたいろいろ調べていたら， boost/preprocessor という秘法を見つけた（たぶんインドの奥地かどっかで）書いてみる． // mixin.hpp #include // for std::list #include // for std::find #include #include #include #include #include // === ここから汎用 Mix-in フレームワーク #define _DEF_DUMMYBASE_METHOD(r, data, elem) \ void elem(); #define _DEF_INTERFACE_USING(r, data, elem) \ using

続続 template × mix-in

2010-12-28T17:20:54+09:00

* 続続 template × mix-in #right{last update: &update(format=Y/m/d (D))} [[なんとかならんのか．>続 template × mix-in]] というわけで，なんとかしてみる． ** その４まず， Interface について考えてみる．重要な制約は， C++ では関数テンプレートが仮想にできないという点だ．よって最後に MixExport した関数テンプレートは，どう頑張っても Interface からは呼べないことになる．やはりこの方針はまずい．で，いろいろ調べていたら using 宣言というのが目に止まった． using namespace std の using ディレクティブとは違い，メソッドやメンバを「引数」にとる．通常，基底クラスで宣言されたメソッドなりメンバなりは，派生クラスで同名のメンバやメソッドが宣言されると隠蔽される．しかし using 宣言することにより，隠蔽をはずすことができる．これだ！書いてみる． // mixin.h #include // for std::list #include // for std::find // コンテナに格納されるクラス class A { /* 省略 */ } class B { /* 省略 */ } // コンテナ機能を付加する Mix-in のインターフェイステンプレート template class MI { public: virtual ~MI() {} void add(T* t) = 0; void remove(T* t) = 0; }; // コンテナ機能を付加する Mix-in のテンプレート template class MixIn { std::list ts; public: typedef T type; MixIn() {} ~MixIn() {} void add(T* t);

続 template × mix-in

2010-12-28T17:14:33+09:00

* 続 template × mix-in #right{last update: &update(format=Y/m/d (D))} [[しかし面倒な．．．なんとかならないのだろうか>template × mix-in]] というわけで，なんとかしてみる． ** その２その前に，少し落ち着いて考えてみる．そもそもメソッドのオーバーロードが必要となったのは，MixInA と MixInB が「ほぼ同じ」機能を持っていたからだ．MixInA と MixInB が全く異なる機能を持っているなら，そもそも同名のメソッドがあること自体，筋が悪い．同名のメソッドが無いならば，複数のクラスを Mix-in してもあまり問題はなさそうだ（実はあるんだが^^）．なので，対処すべきは，複数 Mix-in されるクラスが， - 全て同名のメソッド群を持ち - ただし引数 or 戻り値が全て異なる場合だろう．となれば， Mix-in されるクラスは template 化されているべきだろう．やってみる．MixInA と MixInB の実装をまとめられる以外に，何かご利益があるだろうか． // mixin.h #include // for std::list #include // for std::find // コンテナに格納されるクラス class A { /* 省略 */ } class B { /* 省略 */ } // コンテナ機能を付加する Mix-in のテンプレート template class MixIn { std::list ts; public: MixIn() {} ~MixIn() {} void add(T* t); void remove(T* t); }; // MixIn の実装 template void MixIn::add(T* t) { ts.push_back(t); } template

squirrel_code @ ウィキ