UTF8 BOM無+LF改行コードで書かれたソースのコンパイル Visual C++ 2012 + cocos2d-x

ソースコードをUTF-8 BOM無+LF改行コードで書くのはVC++では鬼門ですね、、、。

一番簡単な例は以下

こんな感じのコードを書いてUTF8n+LFで保存してコンパイルすると一行コメントが行継続されてしまいprintfのある行が完全に無視されます。また、内部的には行継続(\ + 改行コード)ではないので、エラー表示の行番号もずれる事になります。

この現象は改行コードがCR+LFの場合か、BOM有の場合には発生しません。

以下はこの事象について推測含めた考察です。

BOM無の場合、BOMが無いためSystemのDefault Code Page (932)でコンパイラが処理をしてしまいます。どうもコメントの最後の文字がShift-JISの第一バイトのレンジだった場合に次の一文字を無条件で無視しているようで、改行コードが認識されず一行コメント // が次の行まで有効になってしまいます。

改行コードをCR+LFにした場合、CRのみが無視され、次のLF一文字で一行コメントが終端されるため特に問題になりません。

BOM有の場合、BOMからUTF8コードである事をコンパイラが認識してくれるため、きちんとコードが処理されます。この場合文字列定数内の日本語も正常に取り扱う事が出来ます。

UTF8の場合ニバイト目以後に \ 等のエスケープ文字が現れないように工夫されていますので、まぁWarning無視すればいいだろぐらいに思っていたのですが 逆にShift-JISにきちんと対応しているシステムではこんな問題があるんですね、、、。

問題はソースコードのコードページがシステムデフォルト以外を利用できないっぽいって事にあります。/codepageオプションがC/C++のCompilerに提供されていないようです。また、#pragma setlocaleについては文字列定数の中の扱いのみ変更するようなので、コメント行には効果が無いようです。

通常私は文字列定数は全てリソース化し、コメントを英語で全部書くようにしている（勉強の意味で(^^;）ので、問題になっていなかったのですが、先日手を抜いてw日本語を使ったところ、この事象で変なエラーが出て悩まされました。

現状スマートな解決策はないようです。JDKに含まれるnative2asciiのようなpreprocessを挟むか、Single Byte圏のLocaleで実行する以外ないようです。

cocos2d-xを使ってWindows環境をターゲットにする事はあまり無いと思いますが、要注意ということで、、、。

基本の開発環境はMacにするべきという話なのかもなぁ、、、(笑)