以下討論都基于C++的定義

在C++的標準定義中
Type wchar_t is a distinct type whose values can represent distinct
codes for all members of the largest extended character set specified
among the supported locales. Type wchar_t shall have the same
size, signedness, and alignment requirements as one of the other
integral types, called its underlying type.

...

A character literal that begins with the letter L, such as L'x', is a
wide-character literal. A wide-character literal has type wchar_t.
The value of a wide-character literal containing a single c-char has
value equal to the numerical value of the encoding of the c-char in
the execution wide-character set. The value of a wide-character lit-
eral containing multiple c-chars is implementation-defined.

??? 按照我的理解,這意味著:
??? 1. 編譯器需要保證wchar_t與某種整數類型擁有相同的大小,符號,對齊要求.這個"某種整數類型"是由編譯器定義的.這意味著 wchar_t(0x8000 > 1)的結果是取決于編譯器的. 在VC里面,如果設置了編譯選項"/Zc:wchar_t-",那么wchar_t會被默認定義為無符號的"unsigned short".另外"signed wchar_t"或"unsigned wchar_t"在C++是不存在的

??? 2.與C不同,wchar_t必須是一個內建(build-in)類型,我猜這是為了重載和模板特化的需要,看看iostream重載的類型大概就明白了.這里可以引申出另外一個話題: char 既不是 "signed char", 也不是"unsigned char"

??? 3.C++的標準文本沒有將wchar_t 和 unicode關聯起來,標準僅僅要求,wchar_t 能夠用唯一的編碼表示該編譯器所有locale的字符全集中的任何一個字符即可,雖然從需求上來講,wchar_t 也是一種unique-code,但是,一個特立獨行的編譯器,完全有權利定義一套完全不同于unicode的hexie-code,不過,這個hexie-code至少需要保證在數值上,能夠兼容 char 類型的表數范圍,通常意味著 hexie-code的 0-255必須是和char的0-255表示相同的字符

??? 4.眾所周知的,windows的wchar_t是16位,linux的wchar_t是32位

??? 5.截至到VC8, VC的C運行庫是不支持UTF-8的,也就是說setlocale(LC_CTYPE, "zh_CN.UTF-8")是無效的,setlocale(LC_CTYPE, "zh_CN.65001")也不行.單步跟蹤后,發現在getqloc.c中,有以下代碼

??? // verify codepage validity
??? if (!iCodePage || iCodePage == CP_UTF7 || iCodePage == CP_UTF8 ||
??????? !IsValidCodePage((WORD)iCodePage))
??????? return FALSE;

這段代碼是VC8中新加的,VC7中沒有,表現出來的不同是, VC8在setlocale的時候就失敗了,而VC7直到真的使用mbstowcs這些函數的時候才會失敗

http://hi.baidu.com/bbcallen/blog/item/e2e37b1b5add59d3ac6e7549.html

轉載于:https://www.cnblogs.com/duzouzhe/archive/2010/03/29/1700038.html

總結

以上是生活随笔為你收集整理的C++中的wchar_t(转)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。