Application statically linked with Visual C++ 2010 C/C++ runtime fails to launch with error ‘The procedure entry point EncodePointer could not be located in the dynamic link library KERNEL32.dll’.

リンク先を見ると STL や MFC でも C/C++ ランタイムを使っているので同じエラーが出ると書いてあるような気がします。他のサイトなんかも参考にしてみましたが Windows 2000 向けのバイナリは作れないと考えて問題ないのかもしれません。

余談ですが、内部で STL を使ってマルチスレッドを実現するためには _beginthread, _beginthreadex が必要な予感がしていたのですが、この調子ですとやっぱり必要かもしれませんね。

簡単にとはいきませんが、インタフェース（実際にはインタフェースっぽい実装なきクラスですが）とそのインタフェースの代表的な実装（特性オブジェクト）を用意しておいて、クラスに実装＋内包させるという方法がひとつ思い浮かびます。

また、ただ単に振る舞いが増えるだけだと実用性に限界がありそうですので、既存の振る舞いに変化が加えられると嬉しいのかな、とも思います。ただ、そうすると、「変化させてもいいよ」というポイントを（少なくとも特性オブジェクトには）公開しないといけませんね。

…というのを CakePHP を見ながら考えました。 attach() メソッドの手法なら C/C++ でもやってやれないことはないのか。

実は以前、コンピューターの技術で食っていくのをやめようかと思った時期がありまして、持っている本を売りに出してしまったのです。入手できなくならないうちに買いなおそうと思って Amazon に突入です。

この本は最初に読んだ時と、ある程度わかってから読んだ時で違う面を見せてくれるのでためになります。どれだけ勉強が進んでいるかのバロメーター的な存在。

レビューで、「ソースコードの割合が多い」との意見がありましたが、自分は全部本で確認できた方がありがたい気がします（自分が書く本はページ数の関係で無理そうですが…）。

Visual C++ Editions

個人でちょっと頑張って Windows ソフト作っちゃおうかな、とか考えている方（自分もそうなんですけど）はどうしたらいいのでしょうか…

MFC は使わないからいいんですけど SPY++ とか Windows SDK に入ってるっけなぁ…

クラスの設計中はクラスの性質を考えようかとも思うのですが、あとから見ると「あ、これは指示か」とか思うこともあります。ほとんどの場合、指示と指示を受けての振る舞いが近いのであんまり気にならないのですが、なんだか性質を考えていることになるのか疑問に感じるようになります。

噂によると、メッセージと振る舞いとを別に記述できる言語もあるそうですが、どんなんでしょう。考えようによっては Windows もメッセージを受けて処理を決定するという点では別に記述しているような気もします（やたら入力を拒否する反抗的なテキストボックスとかも作れるみたいです）。

時間があったら調べてみたいと思います。

if (someConditions == true)
switch (variable) {
  /* 中略 */
}

例によって if 文を誤ってコピペしてしまったミスなんですが、 if 文の条件を満たす場合のみに続く switch 文が実行されるようになってしまっています。こういうのが嫌なので if 文にはブロックを付けるようにしています。

if (someConditions == true) { /* 中略 */ } // これなら if 文の結果如何に関わらず次の switch が実行される
switch (variable) {
  /* 中略 */
}

今回なぜ外れていたのかわかりませんが、疲れているのでしょうか。

一瞬、疲れすぎて死なないか心配になりましたが、生命線の膨らみが大きく、しかも二重生命線なので体は丈夫とのことです。命拾いしました。余談ですが感情線も二重です。知能線が二重だったらコンプリートだったのに…

プログラミング

　・コンピュータプログラムを作成すること。→プログラミング (コンピュータ)を参照
　・シーケンサーにシーケンスを設定すること。→ミュージックシーケンサーを参照。

普段 Cubase でやってることを指してプログラミングということでしょうか（今は MIDI しかやっておりません）。確かに手続きを記述するという意味では仕事でやっているプログラミングと同じかもしれません。エクスクルーシブ・メッセージなんかはちょっとした関数呼び出しみたいですし。

同人作品の曲に使う音源を選んでいるのですが、ソフト音源（という表現が古いかも）は音質は良いのですが容量が大きいみたいです。作曲マシンがネットブックに近い XP なので重たい処理はハードに逃がしたい…

VBA だとプロシージャと関数とでサブルーチンのようなものを作ることができますが、 C/C++ だと関数です。関数＝機能と考えると、処理のブロックをなんでも関数で実装するのに違和感がなくなってくるのですが、最初は大変かもしれません。

ただ、 VBA の関数は戻り値を捨てられないとか、プロシージャを呼び出すのに Call が必要という仕様は、ソースコードが読みやすくなって良いなぁ、と思いました。 C/C++ を初めて見たときの記号っぽさが苦手だっただけに強く感じます。

VBA で逆に有利だと感じたのは、構造体や参照渡しができるという点です。普段 VBA しかやってなくても、できるだけ楽したいと思っていろんなプログラムを組まれている方は、ゲームプログラミングを覚えるのも楽だと確信しました。

VBA の基礎を活かしてゲームプログラミングを学ぶ際の一番の壁は、イベントドリブンというモデルで考えていた部分をゲームにうまく応用できるかだと思うのですが、ちょうどそのあたりの原稿を書いているので、書店に並んだら「ああ、こうなったか」と笑っていただけると幸いです。

Chapter 14. Boost.PropertyTree

パスをルートから渡すことで途中の構造を柔軟に解析できるというのがポイントかと思いました。これで数値や文字列など基本的な型であれば値を取得することができ、リストの場合はループで巡回することもできると。なんとも便利じゃないですか。

次のゲーム制作には使うところがありませんが、覚えておいて損はなさそうです。

「作曲入門」と銘打っても、読んでみると前提知識が必要なことが多く、文面から「～なのはご存知かと思いますが」といったニュアンスを感じてしまうことがあります。でも、本当に入門したいときは「ご存知」ではないことがほとんどかと思います。結果、 Amazon なんかでよく見る「入門できない」という評価になってしまうのかもしれません。

たとえばコード進行があります。それ以前の話なのですが、コードって思いつくだけで 100 個以上あるのです。本当の入門者は次のことがわかりません。

• 全部覚えないといけないのか？
• 暗記しないといけないのか？
• １曲中にどれだけ使わないといけないのか？
• 逆に１曲中にどれだけ使えるのか？
• どうやって使うのか？

しかしながら、だいたいケアされているのが最後のひとつだけという場合がほとんどでした（自分が読んできた本では、ですが）。この辺、面白いので興味ある方は勉強していただくと良いと思いますが、曲によってはコードを１つだけで構成することもできます。平坦な曲（さして感動もない簡単な曲というか…）で良ければ５つくらいで曲になります（その５つはキーによって変わりますが）。こういった雰囲気だけでもわかってないと読み進めにくいとあっては「入門できない」という判断になっても仕方ないのかもしれません。

今後求められるのは、こういう目に見えない不安をいくつ拾えるかなんですが、まだまだ先の長い戦いになりそうです。