ぬるぽを見かけたら 全力でぶっ叩くのみ


by Denullpo Smasher Hammerson
カレンダー
S M T W T F S
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30

でぬるぽ renewal

以前のやつ、自分で使ってて微妙なところあったので仕様いぢっちゃった。
コンテクストイラネってな感じで。
Denullpo, the pointer checker

で、意味もなくドキュメント7ヶ国語対応。
日本語以外はほとんど機械翻訳任せですが、web用の翻訳フィルタ通して
読むよりはマシかと。

てゆか、今回一番力を入れたのがドキュメントだったり。
PHPで多国語のドキュメントを書き分けるためのライブラリ書いたりとか。
Doxygenみたいにソース内にゴテゴテ書くの嫌いなんで。
殊に、それで多国語対応なんかしたらソース物凄く汚くなるし。
かといって、コメントの言語分けるためだけにbranch作るのも考え物。
マージ面倒だぉ。




…で、今思ったのだが、これでドキュメント書けるようになったらソース側の
コメントは英語に統一するのがいいような気がしてきた。
今回、GCC/VisualC/BorlandC全対応なものを目指してきたのだが、
日本語文字が含まれていると、どう転んでもいろいろと問題あるようで。

まず、日本語環境のVisualCは強制的にCP932(似非Shift_JIS)扱いして
くれるという困り物。Shift_JIS系文字列の厄介物、0x5cを含む2バイト文字
(通称・ダメ文字)の扱いが統一されていないことは、それだけで共用不可を意味する。
…ということで、ダメ文字の発生しない日本語文字セットは、EUC-JPかUTF-8か。

が、EUC-JPもダメ。Microsoft製のEUC-JP(厳密にはCP50932)デコーダは、
3バイトのEUC文字を認識せず、2バイト決めうちにしてくれる。これで余った
多バイト文字の片割れが改行や文字列終端符号(0x22)と癒着してエラーを引き起こす。

ではUTF-8ではどうかというと、これも一癖ある。
VisualCではUnicode BOM相当のコードを付けないと強制的にCP932扱い
してくれやがるんです。そうすると、日本語文字の多くが3バイトなので同様のエラーが
より頻繁に起こることになる。かといって、BOMを付けると今度は他でエラーとなる。

そんなわけで、BOMなしUTF-8で行末を非ASCII文字にしないという変則ルールができた。
(まさか、4バイト以上のUTF-8文字を処理してないってことはないよな…いくらMicrosoftでも)

因みに、改行はCRLFじゃないとだめぽ。
BorlandCでは何故か//形式のコメントだけが改行認識しないというバグが。
[PR]
by denullpo | 2009-08-03 08:32 | 告知