第C9回　ポインタを捨てて、街へ出よう！（集約関係オブジェクト的近未来) 00/10/06

いま、某社の麻雀ゲームの企画文書書いてます。忙しいのか忙しくないのかよくわからない日々を送りつづけてます。なぜに、麻雀の企画文章を私が書かないといけないのかについては定かではありませんが（笑）、この麻雀、プレイヤーから打ち筋を学習するんです。やねうらおが大学のときに独自に研究していた「例からの帰納的学習」ってやつです。しかし、この企画書に添ってプログラムするのは下手すると、自分自身なので、やっぱ、そんな企画やめとこか〜みたいな（笑）

そもそも、打ち筋だけをパラメータとして学習したところで、強くなりませんて…。概念そのものを見つけ出し、見つけた概念を合成し、あらたな概念を作り出すようなタイプでないと。（その昔、A.M.Lenartの論文を参考にしてLISPでそういう学習プログラムを書いたことはある）　そこまでやったとしても、その学習したという成果がプレイヤーに見えないことには、教えたということに対して何の快楽も得られないのではないでしょうか．．。要するに、打ち筋を学習するだなんて、企画レベルで失敗してると思うんです。コンピュータの成長が見てとれなくてはいけないんです。なんや？それなら、コンピュータのレベルに応じて、配牌をインチキしたら簡単やんって言われそうですね。うっ…そうかも（笑）

そういや、yaneSDK2ndの回転のサンプル（サンプル８）は見ていただけたでしょうか。いつもより多めにまわしております＾＾；　結構な速度が出るもんで驚いています。こんなメールももらいました。

ええ、それはバグです（笑）　修正はしません（笑）

さて、前回の続き．．前回、私は、いくつか勘違いをしていて、鈴希さんから指摘をうけたのでいくつか補足します。

まず、派生クラスを基底クラスへ代入したときには、vtableが摩り替わるのではなく最初からあったvtableが破壊されずに残るだけ。そりゃそうですね。代入を単純なビットコピーと考えて良いのはC言語の範疇だけですね。失礼しました。

また、派生クラスを基底クラスへ代入したあと派生クラス側のデストラクタが呼び出されなくて困るのか？と言われたのですが、よく考えてみれば困りませんね。代入後、派生クラス側の関数を呼び出したいことはあるかも知れませんが、スライシングが起こった時点で派生クラス側の関数の呼び出しは不正。前回私が言ったように、派生クラス側で、派生クラス側のメンバにはアクセスしていないことを保証するための構文を導入して、その関数ならばスライシング後も呼び出せるようにすればどうかというのは悪くないにしても、おそらく常識的な実装ならばvtableは１本増える。スライシング後にtypeinfoを得るためだけにvtableが１個増えるならば、最初から基底クラスにメンバとしてtypeinfoを保持するためのメンバを持たせればいいわけで―――というか、派生クラスを基底クラスに代入したあとに、そのtypeinfoって何なんやーみたいな（笑）

きっと、代入のセマンティクスをどう捉えるか、なんだと思いますが、C++は実体を直接扱う（扱える）わけで、このような実体を直接扱う実装系ならば、実体を使った派生クラス→基底クラスへの代入によって、オブジェクトの形が変わるのは当然で、逆にこれが変わらないのならば、実体を直接扱っていることにはならないし、C++の設計理念と反するのではないか、ということですね。もちろん、その通りです。

代入のセマンティクスを追求していくと、とっても興味深い問題になるとは思うのですが、結局のところ、プログラミングとは妥協の産物なので、smalltalkみたいな代入が正しいとか正しくないとか良いとか悪いとか言う問題ではなく、そのプログラミング言語が対象とする領域でどの程度の現実性を持っているかに行き着くのでしょう。そういう意味ではC++は当時としてとても現実的な選択をしていたということですね。

さて。コンストラクタで、例外が発生すると、デストラクタは呼び出されません。逆にコンストラクトが完了していないのに、デストラクタが呼び出されると困ります。たとえば、

A::A() { m_b = new B; m_c = new C; }
A::~A() { delete m_b; delete m_c; }

のようなコードがあって、m_bのnew Bでメモリが足りずにbad_alloc例外が発生すると、m_cの値は不定のままデストラクタが呼び出されることになって、delete m_cの部分で、不正なメモリをdeleteしてしまいます。このような理由により、コンストラクタで例外が発生した場合は、デストラクタは呼び出されません。

よって、コンストラクタでnewしたオブジェクトをデストラクタでdeleteしているから良いということは決してなく、newしたときにbad_alloc例外が発生したときにそなえて、ポインタはすべてauto_ptrでなくてはならない。ふむふむ。auto_ptrが、作られた理由はなんとなくわかってきたぞ。まー、auto_ptrを考えた奴は、それなりに賢かったわけですよ（笑）

それならば、配列のときはどうすればいいのか？auto_ptrの配列版は？それが用意されてないわけです。なんじゃそりゃー！！auto_ptrを考えた奴は、やっぱり馬鹿やったわけですよ（どないやねん．．）　そんなわけで、auto_arrayテンプレートを、用意したので興味のある人は、yaneSDK2ndのYTL/auto_array.hのコードを参考にしてください。

まあ、何故auto_arrayが用意されていないのかは想像だに難くはありません。前回のスライシングの問題です。スライシングの発生する言語処理系では、ポリモーフィックな配列は不可能なのです。具体的に言うと、C++の配列演算はポインタ演算に還元されます。たとえば、A a[10];という配列に対してa[5] == *(A*)((BYTE*)&a[0] + sizeof(A)*5)なわけです。ここでsizeof(A)というのが出てきますが、ポリモーフィックな配列を使えないのは、これが原因です。

ところで、集約関係にあるオブジェクトを、わざわざポインタで管理するのは、

１．遅延生成(lazy construction)
２．ポリモーフィズムのため

の２つでしょう。そもそも集約しているオブジェクト（部分オブジェクト）とライフタイムが同じならば、ポインタなんて使う必要はありません。これ

で十分です。

つまり、ポインタで管理するのは、１．のようにオブジェクトのライフタイムが異なり、遅れて生成されるという場合と、２．のポリモーフィズムな型を与えられる場合の２つしか考えられません。（あとC++では配列サイズを動的に決定する構文を許していないので、そのためだけにポインタを使うことはありますが．．）

ということで、ポリモーフィズムの使えないような配列ポインタは、魅力は半減します。ポリモーフィックな配列を使うために、vector< auto_ptr < A >>で代用する手はあります。要素ひとつ一つに対してnewするため、メモリー効率は悪いです。（しかし、C++でポリモーフィックな配列を実現するには、これが現実的な解決策ですが）

次に２段階初期化構文について考えてみます。これを無くすためには、どうしたら良いのでしょうか？何度も言うように、２段階初期化構文は必要悪という言い方は出来るかも知れませんが、私には必要だとは到底思えません。

たとえば、CPU判別をして、そのCPUに応じて、そのCPU用の派生クラスをnewして返すルーチンを考えてみましょう。

これは、言うまでもなくデザインパターンで言えばFactory Methodの一種です。ところで、このCPlaneBaseが配列になるとどうなるんでしょうか？その初期化は、こんな風になりますか？

ダサいこと極まりないです。もちろん、この解放作業も必要になります。解放作業は、vector<auto_ptr<CPlaneBase> >を使えば少しは楽になりますが、それでも生成がこれだけ鬱陶しいと、嫌になります。ポインタで管理しないといけない、ということ自体が管理コストの増大を意味します。ポインタでの管理は、必要悪ではありません。

どうすれば良いか？解決策は、こうです。

コンストラクタでFactory Methodを呼び出し、auto_ptrでそれを管理します。CPlaneの関数要求は、すべてm_lpPlaneのほうに委譲します。私は以前、これをPrototypeパターンと呼び、「あれはFactory Methodではないのか？」と某所で突っ込まれましたが、違います。Factory Methodは、動的な生成に主眼を置くものであって、ここでは生成そのものが問題ではないのです。また、自分の集約しているオブジェクトを（内部的に）初期化し、外部からのメッセージはすべてその集約オブジェクトに委譲すると言う意味でPrototypeパターンだと言ったのですが、作成動機がPrototypeパターンとは少し異なります。

ここまで読んでくださった方にはいまさら言うまでもなく、私の目的はポインタによる管理から逃れることです。言い換えれば、面倒な初期化作業、解放作業から逃れることです。そういう意味では、これは典型的なデザインパターンのどれにも分類されないのかも知れません。そんなわけで、ここでは仮に代理母パターンと呼ぶことにします。

ポインタでの管理が何の苦痛でも無いという人がいますが、そんな人の書くプログラムは、私は信用できません。ポインタで管理すること自体が管理コストの増大、すなわち、バグの発生率を上げます。まして、初期化作業が必要ならば、初期化忘れが発生します。

本題に戻って、２段階初期化から逃れる方法について説明しましょう。もうわかったかも知れませんが、この代理母パターンのあと、２段階目の初期化関数を呼びます。

これで、２段階初期化からは逃れられます。ただし、このような代理母クラスが必要になります。呼び出された関数をすべて委譲するためのコードが必要になります。実行時のオーバーヘッドは無視できるオーダーでしょうが、このクラスを使うほうは楽でも作るほうは、いちいち保守するのが非常に面倒です。どうすれば良いでしょうか？テンプレートで逃げられないでしょうか？

たぶん、逃げられません（笑）　C++の関数テンプレートの弱さですね＾＾；　たとえば、こんなテンプレートを作って、

template<class T> class surrogate_mother {
public:
    surrogate_mother(){
        m_ptr = new T;
        m_prt -> Init(); // ２段階目初期化
    }
    ~surrogate_mother(){
        delete m_ptr;
    }
    T* operator->() const {return m_ptr;  }

protected:
    T* m_ptr;   //  こいつに委譲するのだ
};

typedef surrogate_mother<CPlaneBase> CPlane;

とかやって、

 CPlane plane;
 plane->Load("xxx.jpg");

とやって使う手はあります。ポインタでも無いのにメンバを呼び出すのが -> というところらへんが非常に気持ち悪い気がします。せめてメンバ参照の . (ドット)をオーバーロードさせてくれ〜って気はします。

結局のところ、例外処理は２段階初期化の問題と摩り替わり、代理母パターンと合流して、テンプレート展開の脆弱さに帰結したのでした。こうやればいいよ！ってアドバイスがあればよろしくお願いします。

継承を言語機能としてサポートしているくせに、クラスのコンポジションの言語的バックアップ（例：上で出てきた委譲するだけのコードを延々と書かなければならないなど）が非常に弱いのがC++の難点です。そのへんをビジュアルに行なえる開発環境があれば良いんでしょうけれど．．．。

第CA回　auto_ptr間のアップキャスト（なんで出来へんの〜) 00/10/12

またもや、うちのおかーちゃんからの電話で起こされました。

「あんた〜、大変や！」

おかーちゃん、どうしたんや？

「あいめが、愛芽がおらんようなった…」

えっ。それは大変や！！えらいこっちゃ！！どうすんねん！って言うか愛芽ってなんや？あんたの隠し子？ということは、俺の生き別れの妹？

「何馬鹿ゆうてんの！愛芽ゆうたら、あい・めーでしょ！」

ああ、なるほど。あい・めーですか？すみません。残念ながら、当方、中国語は理解できません。

「中国語とちごてmath愛芽！」

えっ？何？math愛芽？数学的隠し子ですか？（笑）

「何ゆうてんの！あんたも感じは、math愛芽でしょ！」

俺も、感じはmath愛芽なんか？俺も、math愛芽って感じ〜？ちゅーか、それ何の話なの？

「そりゃウイドウズのんに決まってるやん…」

ウイドウズって何よ？未亡人達？ちゅーか、Windowsですか？（笑）　ということは、感じのmath愛芽って、ひょっとして、漢字入力するMS-IMEのことですか？MS-IMEがmath愛芽…。お笑いか、それ…。

んなもん、Alt+漢字で出てくるんとちゃうんか。どうも話を聞いていると、Alt + ESCを押していたらしい。も〜。朝から阿呆みたいな電話してくんなっちゅーに！

「愛芽はやめて、これからは漢ちゃんって呼ぶようにするわ」

愛芽でいいよ、愛芽で。（笑）

さてさて。今回は、auto_ptrによるアップキャストについて簡単に説明。

auto_ptrが、そんなに利口で、通常のポインタと同じように扱えるならば、継承関係のあるauto_ptr間でアップキャスト出来てもよさそうなもんである。つまり、class Aからclass A_derivedが派生されているとしたら、

ということ。

実際には、AとA_derivedには継承関係があっても、auto_ptr<A>とauto_ptr<A_derived>には継承関係が無いので、これは、失敗します。コンパイラがメンバ関数テンプレートをサポートしていれば、うまくいくのですが、VC++6.0でもメンバ関数テンプレートをサポートしていないので、この変換は出来ません。

どうするかというと、

こんなんでええんか？　所有権の移動まで兼ねて行なうならば、

こうですか？　もちろん、私が作ったauto_arrayのほうは、ポリフォーイズムをサポートしていないので、どちらも不可です。auto_arrayに、要素のひとつのサイズをメンバとして持たせて、operator [ ] をオーバーロードして、

で、配列要素にはうまくアクセスできるので、ポリフォーイックなauto_arrayは可能なのではないでしょうか？

このアイデア、部分的には上手くいくのですが、配列のデストラクタがうまく呼び出されません。デストラクタを明示的に呼び出そうにも、確保されている配列サイズがわからないので、それも不可。あちゃちゃ〜。確保までauto_arrayの構文で明示的に行なおうと思っても、コンストラクタで引数を取る場合は、テンプレートで書けない。つまり、任意の数の引数とマッチして、それをテンプレート展開してくれる構文と、配列のnewで引数付きで行なえる構文が必要なわけですが。イメージとしては、こんな漢字、もとい感じ。

ともかく、そんなわけで、vector<auto_ptr<T> >を使うことになるのです。これのテンプレートは、yaneSDK2ndのYTL/auto_vector_ptr.hがそれです。よかったら参考にしてください。余談ですが、最後の> >は、>>とやると右シフト演算子だとみなされるのでスペースが必要なのです。最大トークン法でparsingするんで、こういうことになるんですね。何か異様にダサい気がするのは私だけでしょうか？？

第CB回　PhotoShopのレイヤ合成アルゴリズムについて（YGAフォーマットを提唱する) 00/10/18

ついにやりました！！アンチェリ転送に成功しました！

yaneSDK2ndのサンプル12で公開しようと思っているのですが、アンチェリ転送に成功しました。ここで、簡単に原理を説明します。

まず、画像からαチャンネル（PhotoShopで言えば「不透明度」）情報を抽出しなくてはなりません。PhotoShopで言えば、PNGの書き出しでそれを行なえますが、PhotoShopは非圧縮PNG書き出しが出来ないので、これを扱うのは非常に不便なのです。

非圧縮PNGについては、さ〜さんのページに資料的価値の高い解説文が存在します。しかし、たかがαチャンネルを抜き出すためだけに、わざわざPNGの読み込みルーチンを作るのは苦痛です。仮にそれがlibpngで簡単に作れるとしても、今度はPNG書き出しが出来ないツールだと大変です。PNGを使わず、そして、もっと簡単になる方法は無いでしょうか？これが今回の課題でした。

そこで、考えたのは、PhotoShopのレイヤ合成のアルゴリズムについてです。私が見る限り、PhotoShopのレイヤ合成は、エネルギー分配に基づくもので、一番手前のレイヤにまず１００％のエネルギーが与えられます。一番手前のレイヤの不透明度が仮に６０％だとすれば、そのレイヤに６０％のエネルギーが割り振られ、残りの４０％のレイヤが後段のレイヤに行きます。後段の（２番目に手前の）レイヤが仮に７５％の不透明度であれば、この４０％のエネルギーの７５％が、２番目に手前のレイヤに割り振られます。つまり、４０％×７５％＝３０％ぶんです。さらに後段のレイヤでは、残った１０％のエネルギーが割り振られます。これを、エネルギーが０になるまでこの処理が繰り返され、割り振られたエネルギーに基づいてピクセルの値（ＲＧＢ）を重み付きで平均を行なうのです。

しかし、単純に２枚のレイヤしか無いときは、

です。ｐは手前のレイヤのピクセル値。ｑは後ろのレイヤのピクセル値。αは手前のレイヤの不透明度（０〜１００％）　いま、αは０〜２５５の間の数字で欲しいので、この式は、

と変形できます。（αは０〜２５５ね）

そして、後ろの（透明な）レイヤを、白に塗った画像Ａと、黒に塗った画像Ｂの２枚を用意します。このとき、ｑの（Ｒ，Ｇ，Ｂ）＝（２５５，２５５，２５５），（０，０，０）ですね。つまり、上の式に代入すると、

です。Ａの画像からＢの画像の差を取ると、（２５５−α，２５５−α，２５５−α）となり、ＲでもＢでもＧのいずれも２５５−αとなるので、２５５からＲの値でも引いてやれば求めるべきαの値となります。

サクっとプログラムを書きましょう。

実に簡単です。あとはこのαチャンネル付きのデータにヘッダをつけて、実際のボディはyaneSDK2ndのCLZSSで圧縮すればαチャンネル付きの画像フォーマットが完成。Yaneurao Graphic format with Alpha channel略してYGAと命名。yaneSDK2ndのCDIB32では標準でこの画像を読めこめるようにしてあります。このあと、αチャンネル有効な転送処理をいくつか追加。

ただし、このα値の有効なブレンド転送は、０−２５５の間なので、さきほどの

で行なわなければならないのですが、この２５５で割る作業が、結構、ハイコストなのでビットシフトで済むように通常、２５６で割ります。そうすると、α＝２５５にもかかわらず色が少し減衰するという現象が発生します。これを防ぐために、αが２５５のときは２５６に補整する処理を入れます。これでバッチリです。ちなみにヌキ色有効な転送は必要ありません。ヌキ色の部分はα＝０にしておけば良いからです。

いま製作中のWAFFLEの『HAPPYほたる荘』で、これをテストしてもらったところ、非常に良好な結果が出たので、『HAPPYほたる荘』の立ちキャラ等は、すべてこの形式で行なうことにしました。

従来、画面のインターフェースはヌキ色の処理が非常に面倒で、グラフィッカーに負担を掛け、かつジャギとの格闘だったのですが、これで完全に解消できたことになります。

Leafの『猪名川で行こう！』にしても、何だかんだ言っても２階調のレイヤマスクしか持っていなかった（と思う）のに対し、αチャンネル付き転送を実装したのは、業界初でしょうか．．？そんなわけで、『HAPPY ほたる荘』買ってくださいね＾＾；

'00/10/19 追加。↑業界初ではなかったらしい（笑）　こんなのぐらい簡単なんだから誰かやってるって…。透明部分を白塗りと黒塗りしたものからα情報を抜き出すあたりは斬新だと思ったんだけどな〜。

'00/10/20 追加。PhotoShopからならばαチャンネルを作って、RAW形式で書き出せばαチャンネルも出せるようだ。参考になりそうなところは、ここかな？手間は、上の方法とそんなに変わらないような...

第CC回　シャッフリングとブレインウオッシュ(ユングそして、プロップへ) 00/10/21

ついに第CC回である。CCと言われても、カードキャプターさくらしか思いつかないダメ人間なやねうらおは、CCレモンと言われても頭のなかではカードキャプターれもんと変換されているし、たぶん、そのへんの感性は誰よりもダメな方向に傾倒しているはずだ。（自慢にならん！）

カードで思い出したのだが、麻雀の研究をするために、京王八王子の雀荘に行ってきた。少し麻雀を打ったあと、ゲーセンで麻雀をして、何度かあがると、景品交換カードが出てきた。これが何なのかわからないまま、カードを店員に渡すと、ショーウィンドゥから、ポイント分の景品を選んで良いという説明を受けた。とても丁寧な口調の店員だった。

少し大きめのぬいぐるみで、Ｔｏ　Ｈｅａｒｔのあかりが置いてあったので、やねうらおは『これ』とだけ言った。すると、別のところに連れていかれ、赤だけでなく、緑のもありますが、どちらがいいですか？と尋ねられた。やねうらおを、特別に優遇してくれたようだ。非常に親切でフレンドリーな店員だと思った。赤と緑…。緑というのは、どうやらマルチのことのようだ。『そうですね〜じゃあ、あかりで』　そう言ったとき、自分のとんでもない失言に気づいた。

あか……り？敵愾心剥き出しの店員の目は、なんだ、このオタク野郎！気持ち悪いんじゃボケぇ！という痛烈な批判を内包していた。店員の表情は、さきほどまでの優しい口調からは想像もつかないほどに豹変していた。その態度は、たとえるなら、いままで６年間付き合っていた国家公務員をしている堅実な彼氏が実は下着泥棒で女装趣味で浣腸マニアで幼女嗜好であったことが一挙に発覚したときの彼女のそれであった。さすがに、鈍いやねうらおも、軽い咳払いをして、咄嗟に言いなおした。『あか！でお願いします！』　刹那…もうさきほどまでの店員の険しい表情はどこにもなかった。赤でございますね。かしこまりました。店員は何ごともなかったかのように平然と赤いぬいぐるみをダンボールからひとつ取り出すと、優しくやねうらおに手渡してくれた。そうだ。これでよかったのだ。最初から、そう言えばよかったのだ。

次に来たときには、また麻雀ゲームをして緑のぬいぐるみをもらおう。やねうらおは、そう思った。あの緑のぬいぐるみの名前は何て言うのだろう？やねうらおは過去に知っていたような気もするが、いまや思い出すことすら出来ない。最近、すっかり経営陣が交代し、はぎやまさかげ氏を始めとしてごそっと優秀な人材が抜けおちて、ファンも萎え萎え（反意語：萌え萌え）な会社だったところまでは思い出せるのだが、緑のぬいぐるみの名前だけは思い出せない。きっと思い出さないほうが良いのだろう。思い出したとしても、また忘れたほうが良いのだろう。世のなか知らないほうがいいこともあるのだから―――。

さてさて、今回は数字をシャッフリングについての考察です。よく、ゲームで、ランダムな数字が欲しいことがあります。ただし、数字はそれぞれ１回ずつしか出てきて欲しくはないのです。このようなランダムな数列を得るのに、次のようなプログラムを書きます。

配列に0...N-1までの数字を代入して、ランダムでM回、２つを抽出して入れ替える。そうすれば、数字の重複は起こらないと、こういう仕組みです。ところで、このときこのシャッフリング回数Mを何回に設定すれば適切か、というのが今回の問題です。上のプログラムをわかりやすく、下のようになおします。

それでは数が少ないときから考えていきましょう。

　☆　N==2のとき、M==1で十分である。なぜなら、１回のシャッフリングで(k1,k2)==(0,0),(0,1),(1,0),(1,1)をそれぞれ等確率で取りうるが、(k1,k2)==(0,0),(1,1)のときは、(v[0],v[1])==(0,1)となり、(k1,k2)==(0,1),(1,0)のときは(v[0],v[1])==(1,0)となるので、v[0]は1/2の確率で0を取るからである。

　☆　N==3のとき、M==1では、(k1,k2)==(0,0),(0,1),...,(2,2)をとるが、１回のシャッフリングでは(v[0],v[1],v[2])==（割愛＾＾）なので、v[0]は5/9の確率で0をとり、2/9の確率で1,2/9の確率で2を取る。よってM==1では不十分である。
　　　 N==3のとき、M==2で、v[0]==0である確率は、１回目のシャッフリングで０がその場所に停留する確率（５／９）×２回目のシャッフリングでもさらに停留しつづける確率（５／９）　＋　１回目のシャッフリングで０がv[1]かv[2]に行く確率(４／９）×２回目のシャッフリングでその０がv[0]に戻ってくる確率（２／９）である ＝　３３／８１である。つまり、M==2でも不十分なのである。
　　　以下、Mをいくら増やしても、数学的帰納法により、1/3にならないことは証明できると思う。（M→∞で、1/3に収束はする）

ということで、まんべんなく散乱するようなシャッフリングは、この方法では不可能なのです。ただ、実用上はそれでも十分だと思うので、もう少し検討を続けます。

ともかくv[i]に、そのままｉが停留される確率があまりに高いと困ると思うので、Ｎ個の配列ならば、v[i]がシャッフリング対象に選ばれない確率は1/N以下であって欲しいと思います。

一回のシャッフリングで２度の選出(Rand)が行なわれるので、M回のシャッフリングでずっとv[i]が選ばれない確率は、(N-1/N)^2Mで、これが1/N以下になるような最小のMを決定すれば良いわけです。mathematicaでちょっと計算してみました。

まあ、NとMの関係について統計的な話を仕方ないので、割愛。ともかく、このような２数の交換によるシャッフリングは、お手軽ですがあまり効率は良く無いですし、完全なシャッフリングはN==2のときしか不可能ということで、普通は、こうやるんですよねー。

ちゅーか、これつい先日まで知らんかったのです。（笑）　上の考えてて、何回ぐらいにしたら妥当なんだろう？とか思って、よく考えたら、これでいいんじゃんとか（笑）　こういうのって当たり前すぎて誰も教えてくれないし、どこにも書いてないから、案外盲点になんだよな〜。

しかし、俺の２０数年間のプログラム人生って、一体、なんやったんや…。自己嫌悪。かくなる上は緑のぬいぐるみに慰めてもらうしか…。（ダメ）

第CD回　Boxing and Unboxing (コピーのセマンティクスを巡って) 00/10/24

いま、知り合いに頼まれてコミケに出すためのゲームを作ってます。４才ぐらいの女の子が出てきて、えっちなことをする、ちょっと恥ずかしいゲームなので、私の名前は匿名にしてもらうように頼んであったんです。そして、その匿名ってのが、今日わかりました！何と、その匿名とは、やねうら某…お前、それじゃ匿名になってへんやろ！！なめとんのか！！このゲームは、ナタデココとか、イチゴのショートケーキとかを女児のパンツの中に入れて、ぐりぐりする描写とかあるんですけど、ＰＴＡとか婦人団体とかが恐いので、やねうら某だけは勘弁してください（笑）

しかし、実力は大差ないのに原画マンの名前だけで売れたり売れなかったりする、この業界の風潮はなんとかならんのでしょうか。まあ、原画マンもピンキリで、うちの原画マンの場合は、エロゲンガーと呼ばれています。毎日、出社するときは、昆虫をモチーフにした仮面なんかつけてバイクに乗って颯爽と登場し「エロゲンガー参上！」　これですよ、これ。（なんや？特撮ヒーローか？）　「地球の平和はオレが守る！エロゲンガー！」とか言いながら、電話応対とお茶くみ、雑用をこなすわけです。そんななかでも、「アンインストール方法がわかりません」とか言う電話がユーザーからあると「うちのゲームを消すだなんて許せん！エロゲンガーをナメテンカー！」と親切丁寧に応対しています。（どこが親切丁寧なんや？）　ユーザー登録ハガキに「絵がどっぺりしている」とか感想に書かれていれば、「オレは明日からエロゲンガー改め、ドッペルゲンガー！」と言ってハガキをこっぱみじんこにしてしまいます。―――って冗談なので本気にしないように（笑）

それはともかく、やねうらおは、ちょっと仕事を抱えすぎなので、このままでは、年内の仕事は、どれかを断らなくてはならないのです。とりあえずは、負担のわりにあんまり儲からないプログラミング本が怪しいかも(笑)

さてさて。今回のお題目はC#についてである。C#については、ASCIIから『C#入門 Microsoftの次世代言語を学ぶ』という本が出ているが、読んでも例がすくなすぎて何を言ってるのかさっぱりわからないので、絶対買わないように。1,900円+税で買って馬鹿を見たやねうらおが言うんだから間違いない（笑） C#について知りたければ、

http://msdn.microsoft.com/net/

のほうから、日本語での言語紹介(WORDで約40ページの文章)と、この本よりはるかに詳しい言語リファレンス(英語:WORDで約280ページ)がダウンロードできる。

C#を実際に使ってみる気はあまりしないのだが、C++の悪い点がかなり改善されていることは注目に値するし、C++の欠点を浮き彫りにしてくれるので、勉強のためには良いかも知れない。また、C++ライクな言語を設計しようという人にとっては、目が離せないだろう。

まあ、やねうらおとしてはNET対応の機能には、特に興味はないし、クラスもJava風かなというぐらいで、特に目新しい箇所は無い気もする。

面白そうなのは、boxingとunboxing、そしてdelegateである。このへん、前述のASCII本ではきちんと説明がされていない。はっきり言って、C#で一番おいしい部分はこの部分のような気がする。そんなわけで、実際にmicrosoftからダウンロードしてきた言語リファレンスを読む。読んでみたところ、delegateは、どうも、ただの関数ポインタ保持クラスっぽいので、たいして面白くはなさそうだった。ポインタを排除したので、関数ポインタを使うための仕組みが必要だったので作ってみたという程度。では、boxingとunboxingについてはどうだろう？（以下の訳文は、やねうらおの手による）

なんや、よーわからんが、object型ってのは、すべての型の基底のようだ。MFCのCObjectみたいな奴？

C#では、classは参照型・structは値型である。参照型なので、boxingしても、boxの中身はポインタで、boxingによって行なわれるのは、ポインタ（参照）のコピーだけなので、同じ実体を指すという仕組みのようだ。

なんか実りが無いのだけど（笑）、ここまで読んできてわかったことは、C#ではクラスはすべて参照型のようである。object型というクラスはC++のvoid*に似てはいるが、ちょっと違うのは、object型への代入は、boxingと呼ばれ、実体をコピーしたあと、そのコピーされた実体への参照（ポインタ）をもらう。逆に、object型から元の型へのコピーはunboxingと呼ばれ、こちらは元の型への参照（ポインタ）を渡す。unboxingのときに型チェックがあることを除けば、それほど不思議な機構ではない。

問題となるのは、このようなboxingとunboxingの恩恵についてである。boxingには値コピーという操作が含まれるが、boxingはそれに見合うような恩恵をもたらすのだろうか？そもそもboxingとunboxingは何のためにあるのか？言語リファレンスは、そこについては何も教えてくれない。自分で考えなければならないようだ。

いくつか整理していこう。object型・class型・インターフェースは参照である。加えて言うならデリゲート、string、配列も参照である。値型は、単純型・struct型・列挙型である。

まず私見ではあるが、クラスを参照型として扱うのは賛成である。参照にしておけばスライシングの問題は発生しないし、ポリモーフィックな配列を問題なく使える。また、structは値型、classは参照型という区別、これも実践的だし洗練されていると思う。そんななかで、boxingは、値型と参照型への掛け橋となる機構のようだ。つまり、値型、たとえばstructから、参照型すなわちobject型への変換のための仕組みだと言える。unboxingは、この逆に、参照型(object)から値型へ戻す仕組みだ。つまり、参照型であるclass型をboxingするメリットはあまり無いのかも知れない。

では、値型を参照型へ変換するのがboxingだとしたら、それはそんなに便利なことなのだろうか？また、実体をコピーしなければならないようなことなのだろうか？それは、どういう場合なんだろうか？これも、デリゲートと同じくポインタを明示的に扱わないようにするために用意された苦し紛れの機構に過ぎないのだろうか？どうも、この部分が、やねうらおにはよくわからない。これと言った使い道もいまのところ思いつかない。そのへんも実際にC#を使ったわけではないので、よくわからない。本当に、これがC#の中心的概念なの？って感じ。

（つづく…？）
誰かboxingの使い道を教えてくれるとありがたいかも＾＾；

第CE回　MediaGXはCrusoeの夢を見るか？ (Fiva買いました＾＾；) 00/10/28

最近、このコーナーの趣旨がずれてきている。このコーナーは、何の役にも立たない、精神の開放（解放ではない）を目指す、プログラミング読み物コンテンツ、あるいは、やねうらお日記帳だったはずだ。「とても役に立ちます！」という感謝のメールを頂戴するごとに、なんでやねん！と突っ込み続けて３００年（いや、そんなに経っちゃいないって…）そろそろ原点に立ち返ったほうがいいのかも知れないとか思ったり思わなかったりするわけだ。

そんなわけで、最近の出来事についてだらだらと書いてみる。自分の使っているパソコンのハードディスクが満杯になった。２８ＧＢ＋１２ＧＢ＝４０ＧＢが溢れたのである。ほとんどはＣＤ−Ｒにバックアップをとってあるので飛んでも大打撃にはならないが、それでもＣＤ−Ｒからいちいちデータを取り出していたのでは仕事にならないので保存する場所が必要である。そこで、緑のぬいぐるみを捕獲するために京王八王子に遊びに行ったついでに、ヨドバシカメラで６０ＧＢの内臓ハードディスクを買った。確か、２７，８００円だったと思うが、１０％のポイント還元があるので、実質２５，０００円だと考えて良いだろう。これを持ち帰ったのだが、あいにくＣＤ−ＲＷをＩＤＥで増設しているので、すでにＩＤＥに空きがない。おまけにUltraATA100なので、いつも使っているパソコンのマザーボードでは認識すらしない。BIOSをアップデートしようにも、マザーボードのメーカー名すらわかんないときたもんだ＾＾；

何がウルトラなのかは知らないが、ウルトラと言われてもウルトラマンしか思いつかないし、ATAと言われても「あたぁ〜」としか読めないやねうらおは、「あたたたたたぁ〜ほわちゃ！」と叫んで、隣で作業をしているグラフィッカーのみずさわひろのパソコンに許可もなく取り付けてやった。みずさわひろは、交通事故で両親を亡くした友達を見るような哀れみの目でやねうらおのことを見ていた。

やねうらおにとって、そんなことはおかまいなしだ。ドンマイドンマイ。オレには緑のぬいぐるみがついている。そう自分に言い聞かせて、とりあえず、ひろひろマッシ〜ン（やねうらお命名）に、ネットワークごしにアクセスするのだ。一応、100BASEで接続されてはいるのだが、大量のデータがあるので、ちっとも早くない。そこにぎゅうぎゅうと詰め込むこと、６時間。やはりデータを取り出すのも早くはない。２８＋１２＋６０ＧＢ＝１００ＧＢの１００ギガショック！になるんとちごたんか。ショックは受けるには受けたが、それは遅すぎるという衝撃だけだった。

そんなわけで、作業用のノートをもう一台買おうと決心し、またもや次の日、ヨドバシカメラに足を運んだわけだ。狙い目はソーテックだと思っていたのだが、ソーテックのｅ−ｎｏｔｅのキーボードはいかにも安っぽい。ソーテックなんぞ、もともと大手にパソコン部品を卸していた部品配給メーカーに過ぎないくせに、いつの間にこんなにでしゃばってきやがったんだ、ぴしぴしぴし。（鞭を打つ音）　そもそも３ｋｇなんて常時持ち運びするには少し重い。主流は1.5Kg前後。シャープのメビウスノートがこれを達成しているが、同性能の日立やＩＢＭ製品に比べて３万ぐらい高い。ブラックTFT液晶がなんぼのもんかは知らんが、同性能で３万も差があると買う気になれんわい。

ＩＢＭのThinkPadは１３万弱だが、こいつは却下。コストパフォーマンスがソーテックと同じぐらいだとしても、ＥＳＣキーがＦ１の上にあるデザインは生理的に嫌だし、デザインは最悪。平仮名の「ろ」が左下にあるakiaのノートパソコン（誰も知らんて…）みたいなもんです。ソフトウェアでキーボードを入れ替えればよさそうなもんですが、やっぱり3Kg強あるのでは持ち運べないし、分厚さもかなりのもんだし…。

さ〜さんが使ってるPanasonicのLet's noteは、2.5インチハードディスクが搭載できる厚みがあるわりには、1.53Kgで100BaseのLANコネクターが付いてたりするんで、なかなかよさげなのですが安いモデルが在庫なしときたもんだ。

新しいVaioはCrusoeを載せていて駆動時間で魅力はあるものの、命令を実行前にソフトウェアデコーディングするのでどれくらい遅いのかよくわからなかったのと、値段は20万前後、しかも在庫なし。

そう考えていたときに目にとまったのが、CasioのFivaの最新機種です。店頭価格99,500円。（ヨドバシカメラはポイント10%還元なので、実質9万と見て良いでしょう）　MediaGX(cyrixの省電力対応PentiumMMX互換チップ)233MHz搭載、6GBという大容量、840グラムという軽さ、64MBメモリ、Windows98SE。何より、キーがそれなりに大きいので入力しやすいし、Casioが独自に開発した800×600の液晶。モバイルタイプのVaio、リブレットでさえ、縦は480が限界だったのに、このサイズで600もあるんですか？もうこれは買いっきゃないでしょう。一応、カタログチェックを．．えっ？カタログ無いんですか？ひとつ古いタイプのならある？バッテリは標準バッテリで３時間。オプションの大容量バッテリで６時間。まー３時間もあれば十分かな。（ちなみに大容量バッテリは23,000円とのこと）

そんなわけで速攻ゲットしたんすよ。

きっと、やねうらおと同じように考えた人が、大量に居たんでしょう。Fiva馬鹿売れの記事がZDNetでも書かれています。
http://www.zdnet.co.jp/shopping/0010/26/w_tnpcimp.html

CD-ROMとFDは無いので、とりあえず100BASEのTypeIIのLANカードをいま加算してもらったばかりのポイントを使って購入。とりあえず、家に持って帰るまで気がつかなかったんですが、このネットワークカードのドライバ、どうやってインストールすんねや！！FDは別売り、しかもポートリプリケータが必要。合わせて2万ちょいするんだよなぁ…。よし、赤外線や。Palm同士でしか使ったことないけど赤外線で飛ばすことにした。そんなわけで眠っているノートパソコン(Pentium133MHz)から、赤外線でファイルを送信！マシンの間は６０ｃｍほど離れていたんですが、何なくキャッチできました。凄すぎ。これ、電波でないから電波妨害／傍受されないし、やっぱ産業スパイとかは、機密情報を赤外線でやりとりしてんのかなぁ．．（６０ｃｍしか離れてないんなら、口で言え！とかいう話もある）

そんなわけで、ソフトをいろいろインストール。まあ6GBもあるんで、容量には困らないが、マシン遅すぎ。これ、体感速度ではPentium133MHzぐらいなんだけど、どうなってんのー？おそらく、極小ハードディスクが異様に遅いのだろう。本体自体はPentiumMMX166ぐらいな感じかなー。おまけに、LANカード抜いたら、カードに黒いインクのようなものがついてるし．．どうも熱で中の何かが溶け出したようだ。おい、大丈夫なんか？危なすぎ。これクレームつけたら、回収もんではないだろうか…。次に、バッテリーテスト。フル充電した状態で、MP3をプレイして放置。これが本当の放置プレイだ（なんのこっちゃ）

結果、１時間20分しかもちませんでした（汗）

なめとんのかと言いたい。HDDアクセス+サウンドでの連続稼動は確かに公正なテストでは無いかも知れない。それならば、HDDアクセスをせず（ただし停止はさせず）、バックライトも最低まで落とし、サウンドはもちろん再生せずで、テストしてみると…。

結果、１時間40分しかもちませんでした（大汗）

えー。これって詐欺ですか？確か、パンフレットに載っていた古い機種はMediaGX233ではなく200で、メモリは64MBではなく32MBだったような気はする。その差ですか？200を233にして、32を64にしたらバッテリー時間は半分になったんか？そんなことが許されていいのか？それでパンフレット出せずにいるんか？ひょっとして、この機種はひそかに回収してるんか？ヨドバシカメラの店員が、嫌そうに「えーホントに買んですかー」という顔をしていた理由がいまわかったような気がするぞ。

そうは言うものの、840グラムで、Windows98SE、64MB、6GB、56Kbpsモデム内臓というのは魅力だ。広辞苑の電子辞書と、Mathematica4を入れて持ち歩いて使っているが、結構便利である。安くで売られていたら買ってはいかが？という感じ。

ついでに、Fivaの後継機が発表になっていた。11月末に発売になり、MediaGX300MHzを搭載し、10GBで840gだそうだ。そっちにしたらよかった（笑）　しかしやねー、調べてみると、その後継機のバッテリパックも、品番は同じなのよねー。ちゅーことは、同じバッテリを使うわけで、クロックが上がった分だけ、さらに駆動時間は減るはず。となると、どう考えても１時間ぐらいしかもたないはずである。それを３時間と書いて「使用環境によって異なります」はないんとちゃうかなー（笑）　Vaioもそうだけど、省電力モードでの時間を書くなっちゅーに。実質、ノーパソは、メーカー公称値の半分ぐらいの時間しかバッテリはもたないということか…。

さてさて。前回の続き。BoxingとUnboxingの使いみちですが、やねうらおには結局わかりませんでした＾＾；

structを値型としてしまったがために、すべての型基底であるobject型(参照型)への変換するためにBoxing/Unboxingという機構が必要になったのかも知れません。すべての型基底としてのobject型の導入は賛否分かれるところで、Javaではテンプレートを導入しない代わりにObject型でそれを代用しようとしていましたが、C#のobject型も、それに近いものがあるのかも知れません。

とゆーか、テンプレートをどうして廃止したのか謎です。delegateの機構を見る限りは、Javaより洗練されていると思ったのに、テンプレートを無くしてしまうとC++からはダウングレードのような気がしてなりません。Windows95→98→SE→MEと進化するごとに遅くなり続けるくせにどこがアップグレードやねん！と突っ込みたくなるMicrosoftのすることなので、人智では到底理解不可能なのかも知れません＾＾；

第CF回　 これからはANTIALIASED_QUALITY(アンチェリ物語完結編＾＾；) 00/11/02

やねうらおは、いまだ半そでシャツ一枚なんですよ。それと言うのも長袖の服とかシャツとか持ってないんですよ。それというのも金が無いからですとも。ええ。会社のみんなからは、ハードディスクとかノーパソ買う金があるんなら、冬服を買え！と突っ込まれまくってますが、ハードディスクとかノーパソを買う金はあっても服を買う金は無いんですよ。わかりますか？わかりますよね？（笑）

それと言うのも、上京してくるときにこちらに冬服を持ってきていなかったからなんですが…。送ってもらおうと思って実家に電話しました。

「あんた、ええとこに電話してきてくれたわ」

なんや？ええとこやったんか？それは、邪魔して悪かったな。オレもテレビドラマ見ててええとこで電話かかってきたらムカっとくるもんな。ほなしゃいなら〜。

「違うがな。ちょっと、相談があんねや」

なんや、相談かいな…。わかったよ。何でも言うてよ。

「それというのも、儒珍トイレがあふれたんや」

えっ！そりゃ大変や。水びたしやな。詰まったんか？キュポキュポせな！

「ちがうがな。儒珍トイレがいっぱいなんや」

せやから、水びたしなんやろ？キュポキュポしたらええがな。

「水は出てへん〜」

なんや？その、儒珍トイレってのは、水洗式とは違うんか？ついに我が家も流行りのシャワートイレとかになったんかと思ったぞ。しかし、うちのトイレ、いつの間に儒珍式になってしもたんや？

「ちがうがな。パソコンで、メール入ってくるトイレがあるやろ？」

えっ？メール入ってくるトイレって何や．．．

「あれが、いっぱいなってしもたんや」

メール入ってくるトイレ、メール入ってくるトイレ・・儒珍トイレ、じゅちんトイレ、じゅしんトイレ・・・それは受信トレイやろ！！何が儒珍トイレなんや、はっきりしゃべれ！はっきり！しかも、トイレじゃなくて、ト・レ・イ。たちつてとのトに、らりるれろのレ、あいうえおのイで、ト・レ・イ。受信ト・レ・イ。おわかり？

「そうとも言う」

そうとしか言わへんちゅーの！

そんなやりとりのあと、冬服を送ってくれるように頼むと…

「ああ？冬服？間違って捨てたわ。ごめんごめん」

捨てたって…何をどう間違ったら捨てられるかな？

「夏にあんたの部屋、掃除してたんや。そしたら、あんたの冬服出てきてな、いま夏やし、これいらんやろとか思って、捨てたわ。ごめんごめん」

ごめんごめんって…（笑）　そりゃ夏に冬服はいらんやろけど、捨てたって、どういうこと？もう無いんですか？

「また買ったらええやん。たんと〜儲けてんねやろ？」

そりゃ、服ぐらい買えるけどやなぁ、馬車馬のように働いてやっと手に入れた金やで！毎年勝手に服、捨てられたんではたまらんがな！

「服はよ買わんと風邪ひくで」

誰が捨てたんじゃい！誰が。まさか捨てたとは思わんかったわい。

「儒珍トイレの件、ありがとーな」

だから、儒珍トイレと違うゆーてるやろ…。

うちの母親は、かなり困った人である。たぶん頭のネジが１６本ぐらい足りないのだろう。

さてさて。今回は、文字フォントのクオリティの話です。::CreateFontでフォントを作成するときに指定できるのは、DEFAULT_QUALITY（ディフォルト）とDRAFT_QUALITY（それなり）、PROOF_QUALITY（ばっちぐー＾＾；）の３つだと思われていますが、それは違うのです。実は、隠しオプションで、NONANTIALIASED_QUALITY（アンチェリなし）とANTIALIASED_QUALITY（アンチェリ有り）というのがあるのです。

どうも、Windows95+MicrosoftPlus!の入っている環境で動くらしいのですが(Windows98以降ならば、Plus!なしで使える)、こいつがまた困ったやつなのです。そもそも、私は自分のWindows2000マシンでPROOF_QUALITYでテストしていたのですが、ルーペで拡大して見たら勝手にアンチェリがかけてあるのです。んなアホな…と思い、別のWindows2000マシンでテストしたところ、そちらではアンチェリがかからないわけです。

調べてみると画面のプロパティ→効果→「スクリーンフォントの縁を滑らかにする」をＯＮにしていると、勝手にアンチェリをかけるようなのです。はっきり言って余計なお世話で、勝手にアンチェリをかけられると、アンチェリ部分はそのときの背景色（yaneSDK2ndのCDIB,CPlaneでは黒）とブレンドした色になるので、それをどこかに描画しようとすると黒が混じってくるのです。

アンチェリなしにするには、「PROOF_QUALITY | NONANTIALIASED_QUALITY」とすればよさそうなものですが、これではうまくいかないのです。なんでかな〜と思って、WinGDI.hを見てビックリ仰天！（死語）

うひゃー。やってくれました（笑） 見ての通り、併用不可なのです。ちゅーことは、たとえばNONANTIALIASED_QUALITYを指定したとき、クオリティは、PROOFなんか、DRAFTなんか、どれやねん！？って思うわけです。困った奴です。そもそも、PROOFとDRAFTの差なんか画面で見てもわかりません。本当に変わってるの！？　謎は深まるばかりです。

考えても無駄っぽいので、とりあえず、アンチェリして欲しいときはANTIALIASED_QUALITY、アンチェリされると困るときは、NONANTIALIASED_QUALITYを指定するしかなさそうです。アンチェリしたかったら、すれば〜？ってときだけPROOF_QUALITYかDRAFT_QUALITYか、DEFAULT_QUALITYを選ぶという使いわけになりそうです。そんなことは、オンラインヘルプに書いとけ！って感じです。

で、さらに実験してるとANTIALIASED_QUALITYを指定しているのにアンチェリがかからない状況が発生。どうも調べてみると、フォントサイズが24以下だとアンチェリがかからないようです。しかも他の環境で試すと、25以上でもアンチェリがかからないときたもんだ。うーん。困ったやつだなぁ…。

こうなってくると、NONANTIALIASED_QUALITYで描画して自前でアンチェリをかけるしか無さそうです。とりあえずぼかし(yaneSDK2ndのCDIB32::ShadeOff)をかけて、それをα値として転送してみたんですが…どうも下手くそ〜な文字に見えます（笑）　だめだこりゃーってことで、正確に縦、横２倍のサイズで描いて、それを縮小するとき、すなわち２×２ドットが１つのドットになるわけで、その４つのドットの加重平均をα値にすればよさそうです。確かにこの方法はうまく行くのですが、正確に縦、横２倍サイズで描くのは不可能なのです。なぜならば、フォントサイズとして２倍を指定したからと言って、文字サイズが正確に２倍になるわけではないからです。まあ、２倍のフォントサイズを指定したときに得られるTextExtentPointの半分の大きさになると考えれば良いのかも知れませんが、アンチェリ文字のときだけ生成されるプレーンのサイズが違うのもまた気持ち悪いのです。

そのへんを適当にごまかしたのがyaneSDK2nd1.00β3のCTextDIB32::UpdateTextAです。動いてるのは、yaneSDK2ndのサンプル13がそれです。

戻る