C + +: How does std::string integrate with Unicode?

keyword: std::string UnicodeTurn from:http://www.vckbase.com/document/viewdoc/?id=1293

once you know how TCHAR and _t work, the problem is simple. The basic idea is that TCHAR is either char or wchar_t, depending on the value of _unicode:

   3: #ifdef _UNICODE

   5:       typedef wchar_t TCHAR;

   7:       #define __T (x) L # # X

   9: #else

  One:      typedef char TCHAR;

  :      #define __T (x) x

  : #endif

When you select the Unicode character set in the project settings, the compiler compiles with the _UNICODE definition. If you choose MBCS (multibyte character set), the compiler will not have a _unicode definition. Everything depends on the value of the _unicode. Similarly, each Windows API function that uses a character pointer has a (ASCII) and A (Wide/unicode) version, and the actual definition of these versions is based on the value of _unicode:

   2:  #ifdef UNICODE

   3:     #define CreateFile Createfilew

   4:  #else

   5:    #define CreateFile Createfilea

   6:  #endif

Similarly, _tprintf and _tscanf correspond to printf and scanf. All versions with "T" replaced the chars with TCHARs. So how do you apply the above to std::string? Very simple. The STL already has a wstring class (defined in the xstring header file) that uses the wide character definition. Both string and wstring are template classes that are defined using TypeDef, and can be used to create string classes of any character type, based on basic_string. the following is the STL-defined string and wstring:

   2:   //(frominclude/xstring)

   3:   typedef basic_string< Char, char_traits< char;, allocator< char > > string;

   4:   typedef basic_string< wchar_t, char_traits< wchar_t, allocator< wchar_t > > wstring;

The template is parameterized by a potential character type (char or wchar_t), so for the TCHAR version, all you have to do is use TCHAR to mimic the righteousness:

now there's a tstring, which is based on tchar--that is, it's either char or wchar_t, depending on _unicode's values. The above demonstrates how STL uses basic_string to implement strings based on any type . Defining a new typedef is not the most effective way to solve this problem. A better approach is to simply define tstring based on string and Wstring, as follows:

   1: #ifdef _UNICODE

   2:    #define Tstring wstring

   3: #else

   4:    #define Tstring string

   5: #endif

This approach is better because the STL has already defined string and wstring, so why use a template to define a new and one of the same string classes? Call it tstring. You can use the #define to define tstring as String and wstring, which avoids creating another template class (although today's compiler is very intelligent, I'm not surprised if it discards the copy class). [typedef does not create a new class, only is to introduce a qualified scope name for a type, and the typedef never defines a new type]. However, once the tstring is defined, it can be encoded as follows:

   1:tstring s = _t ("Hello, World");

   2: _tprintf (_t ("s =%s\n"), S.c_str ());

The Basic_string::c_str method returns a constant pointer to a potential character type, where the character type is either a const char* or a is a const wchar_t*.

by the way, MFC and ATL are now married so that they all use the same string implementations. The combined implementation uses a template class called CStringT , which in a sense has a mechanism similar to STL's basic_string, which can be used to create CString classes based on any potential character type. There are three string types defined in MFC include file Afxstr.h, as follows:

   1:typedef atl::cstringt< wchar_t, strtraitmfc< wchar_t > > CStringW;

   2:typedef atl::cstringt< Char, strtraitmfc< char > > CStringA;

   3:typedef atl::cstringt< TCHAR, strtraitmfc< TCHAR > > CString;

Cstringw,cstringa and CString are exactly what you'd expect: CString wide characters, ASCII and TCHAR versions.

so, which is better, STL or cstirng? Both are good, you can choose your favorite one. But here's one question to consider: which library you want to link to, and whether you're already using Mfc/atl. From a coding point of view, I prefer the two features of CString:

The first is that CString can be initialized easily, regardless of whether you use a wide character or char.

CString S1 = "Foo";

CString s2 = _t ("bar");

Both of these initializations work correctly because CString has made all the necessary conversions for itself. Using the STL string, you must initialize the tstring with _t () because you cannot initialize a wstring through a char* and vice versa.

The second is the automatic conversion of CString to LPCTSTR, which you can code like this:

CString s;

LPCTSTR lpsz = s;

On the other hand, the use of STL must explicitly call C_str to complete this conversion. This is really a bit picky, and some people will argue that it's better to know when to convert. For example, using CString in a function with C-style variadic parameters can be troublesome, like printf:

printf ("s=%s\n", s); Error

printf ("s=%s\n", (LPCTSTR) s); Required for

without coercion, the result is some garbage, because printf wants S to be char*. I'm sure many readers have made this mistake . Preventing this scourge is an undisputed reason for STL designers not to provide conversion operators. But insisted that you call C_STR. In general, like to make use of STL guys tend to theoretical and academic gas, and Redmontonians (translator: Referring to Microsoft) The big boys are more pragmatic and rambling. Hey, anyway,the practical difference between std::string and CString is negligible.

C + +: How does std::string integrate with Unicode?