-styleリテラルを使用する代わりに、'?'
-style文字リテラルを使用して、型であることがわかっている値と比較したり、値に割り当てたりすることの欠点はありますか?wchar_t
L'?'
3 に答える
それらは間違ったデータ型とエンコーディングを持っているので、それは悪い考えです。コンパイラは、標準の整数変換(符号拡張など)を使用して、文字リテラルをサイレントに拡張します(文字列の場合、型の不一致のコンパイルエラーが発生します)。ただし、値が一致しない場合があります。
たとえば、文字0x80から0xffは、多くの場合、異なるUnicodeコードポイントにマップされ、正確なマッピングはコンパイラのコードページによって異なります。
明らかに、UnicodeがID変換を使用してさまざまなコードページすべてをマップすることは不可能です。 単に拡大するだけで十分であれば、のような関数は必要ありませんmbtowcs
。
'\xAB'
対についてのあなたの特定の質問をWRT L'\xAB'
、それらはおそらく等しくありません。http://ideone.com/b1E39を参照してください
私が言ったように、標準は言う
char配列(プレーン、、、
char
またはsigned char
)unsigned char
、char16_t
配列、char32_t
配列、またはwchar_t
配列は、狭い文字リテラルによって初期化できます。
ただし、__STDC_MB_MIGHT_NEQ_WC__
プリプロセッサ定義のセクションでは、
整数定数1は、のエンコーディングで
wchar_t
、基本文字セットのメンバーが、通常の文字リテラルで単独の文字として使用される場合、その値と等しいコード値を持つ必要がないことを示すことを目的としています。
そしてのために__STDC_ISO_10646__
:
yyyymmL形式の整数定数(たとえば、199712L)。この記号が定義されている場合、Unicodeに必要なセットのすべての文字は、タイプのオブジェクトに格納されると
wchar_t
、その文字の短い識別子と同じ値になります。
私は標準の解釈の専門家ではありませんが、それはあなたの質問に対する答えはそれらが異なる表現を持っているかもしれないということを意味すると思います、そしてあなたは常にを使うべきL
です。
唯一の欠点は、EBCDICを使用する石器時代のシステムでプログラムが失敗する可能性があることです。char
検討に値する実際のシステムwchar_t
では、ポータブル文字セットの値はすべてASCIIであり、ますます多く(すべてでwchar_t
はない)でUnicodeコードポイント番号になっています。