VC++2005にて、今までのようにコーディングしても出るエラーについてメモ。
_T("")については、今までも注意深くコーディングしていた人なら全然問題ないはずだが。（わたしゃアウト(爆)）
HWNDをlong（4byte）に変換するのが警告になるのは心臓に悪いなぁ。32bit環境なら実行上問題ないみたいだけど。HandleToLong()やらLongToHandle()やらを使って警告は出なくなるとしても、整数型に変換するなら結局そのサイズを気にしなきゃいけない。実際64bitプロセッサーになったら、HWNDとかも64bitになるのかなぁ。そのままリコンパイルしたら破綻するプログラムが続出しそうな気がするなぁ…。
（例によって今さらだけど、）無償になったというVC++2005Express Editionをインストールしてみた！
ユーザー登録しなきゃいけないのは面倒だけど、それくらいはまぁいいか。Oracleでもやってるしな。
Win32APIを使うにはPSDKも入れないといけなくて面倒だけど、それだけで済むなら、それもまぁいいか。
まだあんまり操作を試してないけど、さすがにVC++4.0よりはいい。のかな？(爆)
手がEclipseに慣れちゃってるもんでそれと比べると違和感があるのは確かだけど、それはしょうがないわなぁ。
ところでExpress Editionって長くて書きにくい言いにくい。何て略すのかな？EX？EXP？
JavaみたいにEE？(爆)
VC++6.0で「プリプロセッサがソースを処理して展開した結果」を確認する方法をメモ。
JavaよりもC言語（C++）が圧倒的に優位なのが、マクロ（プリプロセッサ命令）が使えること。
型と無関係な関数のようにも使えるし、データを列挙するのにも使えるのはとても強力。
でも当然ながら、複雑なマクロを組んでしまうとどういう結果になるのか怪しくなるわけで…。そんな時にはプリプロセッサが出力した内容を確認したくなる。
objファイルのように裏でこっそり展開結果をファイルに出力していてくれれば、わざわざオプションなんかを指定しなくても済むんだけど…まぁあんまり展開結果を見ることはないから、いいか。
VC++で多量の変数をiniファイルに読み書きするとき、下手にコーディングすると、変数の一覧が読み込み関数と書き込み関数の両方に出てきてしまって鬱陶しい。追加や削除があると、2箇所直さなきゃいけなくなってしまうし。
という訳で、それを一箇所にまとめる方法を考えてみた。
と言っても、C++をちょっと知ってる人なら誰でも思いつく方法だけど…。
それにしてもマクロ（プリプロセッサ）は便利だ。Javaにもあったらいいのに。
VC++6.0で、いつもVC++4.0でやっていた如く iniファイルの場所をexeファイルと同じ場所にしようとしたら、アプリケーションの終了時にエラーが発生(汗)
MFCのソースを見たら、m_pszProfileNameをfree()で解放しようとしてエラーになっていた。自分はnewで作ってデストラクタできちんとdeleteしていたから、二重解放およびmalloc⇔newの方式違い(汗)
newで作るのをやめて_tcsdup()を使うようにし、解放処理も無くしたらちゃんと動いた。見た目もすっきりしていい感じ(笑)
しかしこうなると気になるのがVC++4.0でやっていた方法。今までエラーなんか出なかったしな～
と思ってMFCのソースを見てみたら、解放処理なんぞ無い！(爆)
そりゃ今までエラーにならなかったわけだ。
…つまり確保したメモリの解放はプロセスの解放処理で誤魔化してたということか…クラスライブラリの仕様とは思えないな(苦笑)
そんなだからMFCはバカにされるんだよ～。
