仕事で使っているプログラムは「必ず真になる条件」として 1 == 1 という式が頻繁に出てきます。これ、なぜかというと if 文などで式が成り立っているかを引き算で判定していることに起因します。たとえば value < 2 という式が成り立っているかを判定する際には、内部的に value – 2 が計算されるのです。もし、結果が０より小さければ条件が成り立っています。逆に結果が０以上の場合は条件は成り立っていません。

では、なぜこの仕組みと 1 == 1 がつながるのかというと、実は x86 の CPU は計算結果が０かどうかの比較が速いのです。だから 1 == 1 つまり 1 – 1 で結果が０になるか？という調べ方をするんですね。

しかしながら、最近の CPU は速いのでこれはもう true に書き換えても良いのではないかと思います。たぶん最適化で消えると思いますし…

おそらく MS-DOS 時代を駆け巡った方々にはおなじみであろう通説、それは「コンパイラは２重ループの最適化が苦手」というものです。読んで字のごとく、コンパイラは最適化オプションをつけても、ハイパフォーマンスな２重ループのコードを吐きだしてくれなかったのです。そんなわけで、２重ループの代表的な用途であるブロック転送などをアセンブラでガリガリやっていた時代があったのですが、先日、某天才プログラマーに言われてしまいました。

聞く話によると最近のコンパイラは２重ループも速いそうです。知りませんでしたなぁ…。冷静に考えてみると Win32API でゲームが作れるくらい最近のマシンスペックとテクノロジーは進化しているわけですよね。最近、アセンブラ書いてないです。これは幸せなことなのかもしれません。

for (int i = 0; i <10; i++);

printf("%d\n", i);

これが動いてしまうそうです。ちゃんと 10 と表示されるとか。わざわざ for 文の中で変数を宣言する意味が無いですね。もしかしたら cl.exe ではブロックの先頭から末尾が新しいスコープになるように設計されているのかもしれません。なんというか機械的に、まぁ、機械であることには違いないんですけど。

assret() 関数に自分のソースコード中で成り立つ恒等式を記述しておくことで、他のプログラマに対して「私はこの条件を満たしていることを前提に開発している」と主張することができるようになります。もし assert() 関数に書いた条件が満たされない場合は警告が表示されるようになります。

int someFunc(int arg)
{
  // arg は０以外の数値である必要がある
  assert(arg != 0);

  // 関数の中身
}

もし assert() 関数の警告に遭遇してしまった場合は、その仕様がアプリケーション全体として問題ないかを検討し、問題ある場合は、その assert() を使ったプログラマーや上長と議論するなどして解決する必要があります。 CVS と同様で assert() 関数を使う＝ソフトウェアの品質が上がるということではありません。 assert() 関数はきっかけに過ぎません。

また、 assert() 関数には副作用のある式を書くことはできません。これは assert() 関数がリリース時に削除される可能性があるためです（普通は削除します）。

int someFunc(int arg)
{
  // やってはいけない！これはリリース時に無くなる！
  assert(arg++);

  // 関数の中身
}

assert() 関数はエラー処理ではなく、あくまで品質向上の仕組みというわけです。

実際は地面の上で焼いているときでもつっかえ棒があって、普段はめり込んでいて見えないだけだと思うのですが、ちょっと 3D の開発経験がないので何とも言えません。ただ、基本的にゲームはすべてのものがめり込むと考えていただいた方が良いと思います。これからゲーム制作を学ばれる場合はなおさらです。「どうやってめり込まないようにするか？」というテーマだけで 8,000 円くらいする本があるのですが、先日 Amazon で注文してしまいました。いやーん。

今流行の物理エンジンってどうなんでしょうか？何であって何でないのか？めりこみとか起こらないのか？興味をそそります。

一見、正常終了が０とは不自然のように思います。なぜなら if (0) は false になるからです。しかし、これはコマンドラインからプログラムが正常終了したかの判断材料とするために、「正常終了したら０を返す」と広く決まっているのです（仕様なのか慣例なのかはわかりません）。つまり、「０が返ってきたら正常終了したとみなそう」というわけです。

Windows は GUI が中心ですのであまりピンとこないかもしれませんが、 Linux などでは各コマンドが正常終了した場合は決まって０が返ってきます。これを見越してシェルスクリプトを作ったりもします。

ちなみに Visual C++ でプログラムを実行して終了した場合、「出力」ウィンドウに「プログラムはコード 0 (0×0) で終了しました。」のようなメッセージが出てきますが、これこそ return 0; の結果なのです。

その昔、 Windows 対応のジョイパッドと言えば十時キーを搭載したファミコンタイプのものが主流でした（少なくとも近所の電気屋にはそれしか売っていませんでした）。

しかし、プレステの DualShock が登場したあたりから Windows 対応のジョイパッドにもアナログスティックを搭載したタイプが登場するようになりました。

当時不思議だったのが、後発であるはずのアナログスティックのタイプが Windows に対して何の更新や設定もなしに使えるということでした。

さすがは Windows 。こうなることを見越してアナログ入力にも対応していたのかぁ～、などと感心してしまったのですが、ジョイパッドのさらに前身にジョイスティックというアナログ入力デバイスが存在していたことを知り、一気に熱が冷めました。つまり、アナログ入力が最初だったのです。

だからジョイパッドから入力キーを取得するとX軸とY軸という区別でデータが取得されるんですね。

納得しました。

たとえば items[10] という変数があったとき…

10[items] と書いてもコンパイルが通ります。

もちろん構文エラーも論理エラーもありません。

配列がポインタとポインタ演算で成り立っているからこそ成り立つこのネタ。つまり items[10] というのは items+10 と同じ意味なんですね。足し算は順番を入れ替えても成り立ちますから 10+items というのは正しいのです。

この点に関して、ある著名なプログラマは自身の本でこう言ったそうです。

名言ですね。