wchar_t built-in or alias (wchar_t is an alias of 16 integers under Windows, and a 32-bit integer under Linux platforms). MSVC2008 Start by default is/zc:wchar_t)

After the first C + + ABI name adaptation (Take QT as an example), continue to look at the C + + name adaptation related issues.

Problem

• MSVC has a pair of options /zc:wchar_t- and /zc:wchar_t control wchar_t

• So wchar_t can be unsigned short or __wchar_t(called native type?). ) is aliased

What would you do with two things mixed up?

First of all, will it be mixed? , is it unfounded? The former /zc:wchar_t-is used by Qt as a binary package provided by MSVC. Consider:

• What happens if you compile your QT program with the latter enabled?
• If the QT program uses a different C + + library at the same time, the library compiles with the latter. What will happen?

Of course

• We can self-enable /zc:wchar_t to compile QT to solve this problem. This article does not consider this situation.

wchar_t

• Section 5.2 of the Unicode 4.0 standard mentions:

The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs, need to being portable across any C or C + + compilershould not use wchar_t for storing Unicode Tex T. The wchar_t type is intended for storing compiler-defined wide characters, which could be Unicode characters in some comp Ilers. "

• C, C + + standards for this wchar_t is not clear enough (so that c++0x, C1x introduced char16_t/char32_t)
• When each compiler implements wchar_t, an alias is defined through a typedef. Under Windows is an alias of 16 integers, and a 32-bit integer under a Linux platform.

Msvc

MSVC, wchar_t has been associated with two of its internal types

• unsigned short

• __wchar_t

wchar_t can be an alias of either, set by /zc:wchar_t- and /zc:wchar_t

Before MSVC2008, the default is the former, starting with MSVC2008 and changing to the latter by default.

Example

Intuitively, generate a dynamic library directly with MSVC and then look at the symbols it exports:

• Source file Dll.cpp

Dll.cpp#include <string>__declspec (dllexport) wchar_t * FUNC1 () { return 0;} __declspec (dllexport) void Func2 (wchar_t *) Span id= "line-10" class= "anchor" >{}__declspec (dllexport) std::wstring generatestring () {< Span id= "line-15" class= "anchor" > return std::wstring (); }__declspec (dllexport) void receivestring (std::wstring str) { }             /span>     

• Compile the above files with two wchar_t, and generate Out0.dll and Out1.dll respectively.

cl/ehsc/zc:wchar_t   /ld dll.cpp  /feout0.dllcl/ehsc/zc:wchar_t-  /ld dll.cpp  /feout1.dll

• Then, use DUMPBIN to view the exported symbols

Dumpbin/exports out0.dlldumpbin/exports out1.dll

Export symbols

For native types: Note that _w represents the type of wchar_t that is __wchar_t

[Email protected] @YAPA_WXZ [email protected]@[email protected] [email protected]@[email protected][email Protected][email protected]@@[email protected][email protected]@@[email protected] @XZ [email protected]@[email Protected][email protected][email protected]@@[email protected][email protected]@@[email Protected]@@Z  

For unsigned short type: Note that G represents the type of wchar_t that is unsigned short

[Email protected] @YAPAGXZ [email protected]@[email protected] [email protected]@[email protected][email Protected]@[email protected]@[email protected]@[email protected]@[email protected] @XZ [email protected]@[email Protected][email protected]@[email protected]@[email protected]@[email protected]@[email Protected]@@Z  

After the adaptation of the name is different, if mixed: certainly will be unable to find the name you are looking for, and there is a link error.

The effects on QT

When mixing two kinds of wchar_t,

All functions that use std::wstring or wchar_t are affected, such as

QString qstring::fromstdwstring (const std::wstring & str)std::wstring qstring::tostdwstring () constINT Qstring::towchararray (wchar_t * array) constQString qstring::fromwchararray (const wchar_t * string, int size =-1)  

How to solve it? The solution is to not use these functions in this case (it seems very unreasonable, and some are unacceptable?) )。

but Http://developer.qt.nokia.com saw someone give a plan, well, even as we said just now, the method is not to use these functions under MSVC, but it just doesn't seem too difficult to accept.

/*! Custom Qstring-to-std::wstring conversion package */Std::wstring qtostdwstring (const QString &STR){ #ifdef _msc_ver return std::wstring ((const wchar_t *) str.utf16 ());  #else  return str.tostdwstring ();  #endif } /*! Custom std::wstring to QString conversion encapsulation */qstring stdwtoqstring (const std::wstring & STR) { #ifdef _msc_ver return Qstring::fromutf16 ((const ushort *) STR.C_STR ());  #else  return qstring::fromstdwstring (str );  #endif }       

Reference

• Http://www.agner.org/optimize/calling_conventions.pdf

• Http://en.wikipedia.org/wiki/Name_mangling

• Http://stackoverflow.com/questions/4667266/c-name-mangling-by-hand

• http://labs.qt.nokia.com/2009/08/12/some-thoughts-on-binary-compatibility/

• Http://developer.qt.nokia.com/wiki/toStdWStringAndBuiltInWchar_SimplifiedChinese

http://blog.csdn.net/dbzhang800/article/details/6707152

wchar_t built-in or alias (wchar_t is an alias of 16 integers under Windows, and a 32-bit integer under Linux platforms). MSVC2008 Start by default is/zc:wchar_t)