kib*_*ibu 5 c++ windows unicode
我正在用c ++为Windows编写一个新的(个人爱好)应用程序.
在以前的低级Windows中,我使用_TCHAR(或只是TCHAR)数组/ basic_strings进行字符串操作.
如果我不关心Win2k之前的Windows平台,那么使用_TCHAR直接使用Unicode 是否有任何优势？wchar_t
编辑:提交后我在2008年10月发现了一个类似的问题:
现在似乎对放弃TCHAR更加一致
Jar*_*Par 13
不,那里没有.跟wchar_t一起去吧.
只有当您希望能够使用条件编译开关将程序转换为以ASCII模式运行时,TCHAR才有用.由于Win2K及以上是unicode平台,因此此交换机不提供任何值.相反,你要暗示你的项目中的其他开发人员,ASCII是一个有效的目标,而事实上并非如此.
wchar_t是一个c ++定义的类型,在Visual Studio中是16位,但在各种gcc编译器中是32位.它总是能够持有unicode代码点.
TCHAR并且_TCHAR不是"unicode"字符 - 它们意味着用于可能在Unicode或Ansi程序中编译和/或使用的代码:
_TCHAR是 - 从其领先的下划线 - Microsoft C运行时库"扩展"到c ++标准._TCHAR会,当_UNICODE被定义,是一个16位的字符,当_MBCS被定义,是一个多字节字符,也不被定义时,是一个单字节字符.如果使用MS CRT定义的带有前缀的字符串函数,请使用此类型_t:_tcscpy()例如,替换为strcpy()/ wcscpy().
TCHAR是由Win32 API定义的.这类型是CHAR当UNICODE没有定义,并且WCHAR当UNICODE被定义(注意这种类型的缺乏下划线的).称取字符串的Windows API函数同样希望WCHAR在字符串UNICODE构建和CHAR字符串非Unicode版本.
总结一下:
wchar_t 是一个跨平台的c ++定义类型,可以保存unicode代码点 - 在Microsoft以外的编译器上,通常是32位宽._TCHAR是一个微软定义的类型,它与_tcs*c运行时函数配对,根据_UNICODE和/或的定义更改其类型_MBCS.TCHAR是一个Windows API定义类型,它根据的定义(或不定义)更改其类型UNICODE.WCHAR是用于处理unicode字符串的本机Windows API类型.当使用GCC工具集来构建Windows代码时,这可能是16位宽,wchar_t而不是.这有帮助吗？我不知道.