5

-styleリテラルを使用する代わりに、'?'-style文字リテラルを使用して、型であることがわかっている値と比較したり、値に割り当てたりすることの欠点はありますか?wchar_tL'?'

4

3 に答える 3

6

それらは間違ったデータ型とエンコーディングを持っているので、それは悪い考えです。コンパイラは、標準の整数変換(符号拡張など)を使用して、文字リテラルをサイレントに拡張します(文字列の場合、型の不一致のコンパイルエラーが発生します)。ただし、値が一致しない場合があります。

たとえば、文字0x80から0xffは、多くの場合、異なるUnicodeコードポイントにマップされ、正確なマッピングはコンパイラのコードページによって異なります。

明らかに、UnicodeがID変換を使用してさまざまなコードページすべてをマップすることは不可能です。 単に拡大するだけで十分であれば、のような関数は必要ありませんmbtowcs

'\xAB'対についてのあなたの特定の質問をWRT L'\xAB'、それらはおそらく等しくありません。http://ideone.com/b1E39を参照してください

于 2012-07-17T16:20:11.513 に答える
3

私が言ったように、標準は言う

char配列(プレーン、、、charまたはsigned charunsigned charchar16_t配列、char32_t配列、またはwchar_t配列は、狭い文字リテラルによって初期化できます。

ただし、__STDC_MB_MIGHT_NEQ_WC__プリプロセッサ定義のセクションでは、

整数定数1は、のエンコーディングでwchar_t、基本文字セットのメンバーが、通常の文字リテラルで単独の文字として使用される場合、その値と等しいコード値を持つ必要がないことを示すことを目的としています。

そしてのために__STDC_ISO_10646__

yyyymmL形式の整数定数(たとえば、199712L)。この記号が定義されている場合、Unicodeに必要なセットのすべての文字は、タイプのオブジェクトに格納されるとwchar_t、その文字の短い識別子と同じ値になります。

私は標準の解釈の専門家ではありませんが、それはあなたの質問に対する答えはそれらが異なる表現を持っているかもしれないということを意味すると思います、そしてあなたは常にを使うべきLです。

于 2012-07-17T16:27:03.223 に答える
1

唯一の欠点は、EBCDICを使用する石器時代のシステムでプログラムが失敗する可能性があることです。char検討に値する実際のシステムwchar_tでは、ポータブル文字セットの値はすべてASCIIであり、ますます多く(すべてでwchar_tはない)でUnicodeコードポイント番号になっています。

于 2012-07-18T01:17:50.273 に答える