といっても、自分で解くわけじゃない。機械に解かせてみようと思ったのだ。で、できたのがこれ。ZIP ファイルにソースコードと結果の画像が入っている。自分で解きたい方は画像の方は見ないように。

・numplc.zip

　ソースの拡張子は cxx だが、ほとんど C 言語だ。たいていのコンパイラでコンパイルできると思う。実行は、以下のような感じでパラメータとして問題を与える。９×９のマスを、左上から右方向・下方向に数字を羅列する。空欄は０にする。なんとも適当な作りだ。

 ./numplc.exe  005300000800000020070010500400005300010070006003200080060500009004000030000009700

　なんで今回こんなことをやったかというと、何年も前に同じものをでっちあげたことがあったからだ。当時、母と兄が数独にハマっており、自動的に解くプログラムを Microsoft Excel の VBA マクロで作ったら「お前はなんてイヤな奴だ」と言われたことがあった。まぁ楽しみを奪うつもりはなかったのだが、そう言われるのも仕方がないかもしれない。

　話を戻そう。で、「世界一難しい問題」ということで、当時の自分のロジックが通用するかどうか試してみたかったのだ。今回は C で書いたが、覚えている限りで実装してみたところ、簡単に誤った解答をハジき出して平気な顔をされた。こりゃいかんとイジり回して完成させたわけだ。結果わかったことは、初歩的な消去法だけでは解答できないということ。「ここが仮に３だったら‥‥‥」などといった仮定のもとに進め、矛盾に行き当たったら仮定を置いたところまで戻って別の選択肢を‥‥‥というのを再帰的に繰り返していかないとダメだった。300～400 行程度のプログラムだが、なかなか面白かった。

　計画的に作ったわけじゃないので、あまりキレイなコードじゃないし、最適化の余地が至るところに残っている。それに、そもそもちゃんと C++ で作れば良かった。そうすれば同じロジックで４×４のを解いたりもできたかもしれない。ま、それはそれで。

・おやじのための自炊講座～おやじの旬魚旬菜

  struct Record {
      char item1[16];
      char item2[8];
      char item3[24];
      char item4[8];
  };
    
  void foo( const char* pData ) {
      const Record* pRecord = (const Record*)pData;
      // :
      // :
      // :
  }

　ここで問題になるのは、「何処かから飛んでくる」データの長さだ。上の Record 構造体のサイズはそれに合わせておく必要があるが、こういうのは変動したりするし、そうでなくても人間の目でチェックするのは面倒だしミスの元にもなる。機械的なチェックがしたいわけだ。

　最初に考えつくのは、assert を使用したものだ。ベタ詰めの文字列の長さが 56 と決まっているのであれば、例えば以下のように。

  assert( sizeof(Record) == 56 );

　ちなみに、文字列長を strlen で調べて構造体サイズとの一致を assert でチェックするのもあるが、これはどちらかというと文字列長のチェックだ（pDataがNULL終端しているという前提）。

  void foo( const char* pData ) {
      assert( sizeof(Record) == strlen( pData ) );
      const Record* pRecord = (const Record*)pData;
  }

　そして、これらは実行時チェックだ。そこが問題である。ランタイムに依存しないチェックが実行時まで持ち越されるのはおかしい。というわけで次に思いついたのは以下のような間違った（実際には動作しない）チェック。

  #if sizeof(Record) != 56
    #error "size mismatch!"
  #endif

　これはコンパイラではなくプリプロセッサが処理するものだから、そもそも sizeof 演算子が使えるわけがない。ここに至って、コンパイル時点でのチェックを C 言語でやる方法を自分は知らないことに気付く。

　そこで、C++ 前提でテンプレートを使う方法を考えてみた。まず、記述は以下のようになる。コンパイラがこのインスタンス化に失敗すればコンパイルエラーにできる。

  SizeChecker<Record, 56> recordSizeCheck;

　で、SizeChecker クラステンプレートは以下のようにする。同様にクラステンプレートである SizeCheckerImp からの派生とし、与えられた構成体の実サイズと想定サイズの差をテンプレートパラメータとして与えているわけだ。

  template <typename STRUCT, int SIZE>
  class SizeChecker : public SizeCheckerImp<sizeof(STRUCT)-SIZE> {
  };

　これで、SizeCheckerImp<0> からの派生の場合のみコンパイルに成功すれば良い。そこで、以下のようにした。

  template <int N> class SizeCheckerImp {
  private:
  	SizeCheckerImp( ) { };
  };
  template <> class SizeCheckerImp<0> { };

　SizeCheckerImp の本体はコンストラクタを private にし、特殊化でテンプレートパラメータが０の場合だけ別扱いとする。こうすれば、SizeChecker テンプレートに与えた構造体のサイズが想定サイズでない場合にのみコンパイルエラーになる。

　ここではクラステンプレートを２つ使ったが、できれば１つにしたいし、そもそも C 言語で簡単にやれる方が良いが今のところ思いつかない。とりあえずは自分の目的は達成できたので、ひとまず良しとしよう。

・殺人博物館　きちんと後始末
・殺人博物館　シリアル・キラーズ
・殺人博物館　女でも殺す

　また、しばらく前に公開されたもので、オススメしたいのが『ドクター尾上のすぐわかる性感染症』だ。自分には関係ない、と考える人は多いだろうがさにあらず。大人の必須教養と言っても良いと思う。

　その他、立読版を除けば全部でコンテンツは14種類になった。一覧はこちらを参照されたし。マイカ出版と協力の上、今後も少しずつ増やしていく予定だ。

　．．．結果、自分のやりたいこと、作りたいものが全部ストップしている。

　所詮は趣味の領域なので、それをやらなければ生活に困るとかいうわけではない。生活に困るかどうかという意味では、半年以上続いた無収入の期間の方がよほど困っていた。貯蓄を削り続けていたからだ。時間はあるが金が無い（というか減っていく）生活。しかし、実際に仕事中心の生活に戻ってみると、それが単に「金は少しずつ貯まっていくが時間が無い生活」に切り替わっただけであることに気付く。

　作りたいものを、作りたい。

　何で悩んでいるかというと、エンディアンを little ─ big 間で相互に変換する際の処理で一番早いのがどれか、自分では判断がつかないのだ。候補として扱う条件は、分岐やループなど、遅くなる要因がないことや、可能な限り局所変数の数や演算の量が少ないこと。扱うのは 32 ビット変数のみと（ひとまずは）しておく。最初は std::reverse() で片付けようかと思ったが、ループやスワップが多いので論外。で、ひとまずイケそうなのは以下の２つと考えた。無論、int が 32 ビット幅だという前提はあるものとする。

int endian_invert( int n ) {
    return ( ( n & 0xFF000000 ) >> 24 ) |
           ( ( n & 0x00FF0000 ) >>  8 ) |
           ( ( n & 0x0000FF00 ) <<  8 ) |
           ( ( n & 0x000000FF ) << 24 );
};

int endian_invert( int n ) {
    union { int val; char ch[4]; } wk;
    wk.ch[3] = ((char*)&n)[0];
    wk.ch[2] = ((char*)&n)[1];
    wk.ch[1] = ((char*)&n)[2];
    wk.ch[0] = ((char*)&n)[3];
    return wk.val;
};

　正直言って、どちらが速いのか自分にはわからない。アセンブルリストを出してみた限りでは、後者の方が短いようだ。自分の無根拠な直観も、後者の方が速いのかな‥‥‥と思ってはいる。しかし、アセンブルリスト上で１行でも、命令によって実際に実行するのにかかる処理コストは異なるという話を聞いたことがある。しかし、そもそも自分はアセンブラを読めない、で困っているというわけだ。こういうときの判断のためのガイドラインとか知っている方、教えて下さい。

　あと、毎日昼飯を外で食べるのは財布に優しくない。そりゃ仕事についたんだから仕方ないが、この仕事のお金が入るのは５月の末。それまで毎日昼メシ外でか。弁当買ったって500円。正直厳しいが、この出費を厳しいと認識するほど逼迫してる自分の立ち位置そのものが厳しい。いろんな意味で危機だ。

　「なんでPalmやねん」の MA-CY さんは、『ちょっとごついですね』 と書かれている。気になったので、Acceca 新デバイスのスペック表と Palm TX の（適当な）実寸を比べてみた。

　まず、重さは 196g で、Palm TX は 150g。Aceeca の方がちょっと重いようだ。次に、デバイスのボディサイズだが、Aceeca は 128 x 76 x 25 mm で、Palm TX は 120 x 75 x 13 mm 程度。TX よりも縦に少し長く、幅はほとんど同じ。厚みが２倍近くあるのが気になるところだ。ついでに書いておくと、Aceeca のは 5-Way Rocker 搭載だが、アプリケーションボタンは２つしかないようだ。そして、WiFi および Bluetooth はオプションである、とされている。

　おそらく、MA-CY さんでなくとも 「ちょっとゴツいな」 と思ったはずだが、それはディプレイに対して筐体が大きく見えるからだ。しかし、厚みを除けば実は Palm TX とほぼ同じ。実は、この Aceeca のデバイス、ディスプレイは W320 x H480 ピクセルで Palm TX と同じ解像度ではあるものの、スペック表には表示領域実寸が W46.64 x H68.95mm と書かれている。一方、手元の Palm TX の画面実寸は W53 x H80 mm なので、より細かいドットを使用していることになる。つまり、筐体サイズはほぼ同じで画面解像度も同じだが、物理的な画面のサイズだけが小さいのだ。

　ここまでをまとめると、筐体サイズは TX とほぼ同じで厚さだけ２倍、少し重く、画面は（解像度は同じだが）物理的に小さい。うん、それほど悪くないような気がしてきた。ただ、デザイン的な意味でバランスが悪いのが気になるところ。しかし、$199 というのは魅力的な値段ではある。国内で購入した場合いくらになるのか、またオプションとされている WiFi や Bluetooth をつけた場合にどうなるのか。やっぱり気になる。

　なんでそんなことをやろうと思ったかというと、陰郎は TX よりも Tungsten T5 のボディの方が好きなのだ。メタリックな表面が高級感を感じさせてくれるからだろうか。実際には両方ともプラスチックなのだが。写真は、このブログの以前のエントリから。

　ちなみに、別にエイプリルフールのネタにしようと思ったわけではない。人様のエイプリルフールネタは楽しませて頂いているが、陰郎は自分でやろうとは思わない。自分がやっても（多分）面白くないからだ。

・灼熱の走路１
・灼熱の走路２
・殺人博物館　きちんと後始末

　「灼熱の走路」は、あの「ゲームセンターあらし」の作者であるすがやみつるさんの著書だ。陰郎は F1 などのカーレースにはあまり詳しくないが、そんな門外漢でも十分楽しめる。２本立てでボリュームもたっぷりだ。オススメ。

　もう１本の「殺人博物館　きちんと後始末」は、古今東西の殺人事件について死体処理に注目してまとめた書籍だ。ちょっとグロいが、平気な人は楽しめるだろう。これもオススメ。

　少なくともこの５年で、自分の開発ベースも大きく変わった。昔は開発環境といえば Visual C++ を使っているだけだったが、今では基本的に g++。UNIX 系も Mac も Windows も使うし、Palm 環境なら 16bit だし仕事では 64bit も使う。文字コードだって少なくとも４種類以上は使っているのだ。全部とは言わなくても、これらをカバーしたいと思ったら、何らかの手を加える必要があるだろう。そしてその修正内容たるや大きなものだ。もちろん新しい機能も付け加えたい。

　以前にも書いたことがあるが、自分が昔作成したプログラムに手を入れるのは良いことだ。他人の作ったプログラムから得るものも多いが、過去の自分の作品を振り返ることには別の意味がある。それは、当時自分がどこにいるかを知り、それによって自分が今どこにいるのか、そしてどこに行こうとしているのかを知ることができるということだ。自分の昔の作品を見ると恥ずかしくなることがあるが、それは良いことと言うべきだろう。それは自分が変化（そして願わくば向上）していることの証なのだから。