在构造CString时使用带符号或无符号字符？

Question

I am check the document for CString . In the following statement:

• CStringT( LPCSTR lpsz ) : Constructs a Unicode CStringT from an ANSI string. You can also use this constructor to load a string resource as shown in the example below.

• CStringT( LPCWSTR lpsz ) : Constructs a CStringT from a Unicode string.

• CStringT( const unsigned char* psz ) : Allows you to construct a CStringT from a pointer to unsigned char .

I have some questions:

1. Why are there two versions, one for const char* ( LPCSTR ) and one for unsigned char* ? Which version should I use for different cases? For example, does CStringT("Hello") use the first or second version? When getting a null-terminated string from a third-party, such as sqlite3_column_text() ( see here ), should I convert it to char* or unsigned char * ? ie, should I use CString((LPCSTR)sqlite3_column_text(...)) or CString(sqlite3_column_text(...)) ? It seems that both will work, is that right?

2. Why does the char* version construct a "Unicode" CStringT but the unsigned char* version will construct a CStringT ? CStringT is a templated class to indicate all 3 instances, ie, CString , CStringA , CStringW , so why the emphasis on "Unicode" CStringT when constructing using LPCSTR ( const char* )?

Answer 1

LPCSTR is just const char* , not const signed char* . char is signed or unsigned depending on compiler implementation, but char , signed char , and unsigned char are 3 distinct types for purposes of overloading. String literals in C++ are of type const char[] , so CStringT("Hello") will always use the LPCSTR constructor, never the unsigned char* constructor.

sqlite3_column_text(...) returns unsigned char* because it returns UTF-8 encoded text. I don't know what the unsigned char* constructor of CStringT actually does (it has something to do with MBCS strings), but the LPCSTR constructor performs a conversion from ANSI to UNICODE using the user's default locale. That would destroy UTF-8 text that contains non-ASCII characters.

Your best option in that case is to convert the UTF-8 text to UTF-16 (using MultiByteToWideChar() or equivalent, or simply using sqlite3_column_text16() instead, which returns UTF-16 encoded text), and then use the LPCWSTR ( const wchar_t* ) constructor of CStringT , as Windows uses wchar_t for UTF-16 data.

Answer 2

tl;dr: Use either of the following:

• CStringW value( sqlite3_column_text16() ); (optionally setting SQLite's internal encoding to UTF-16), or
• CStringW value( CA2WEX( sqlite3_column_text(), CP_UTF8 ) );

Everything else is just not going to work out, one way or another.

---

First things first: CStringT is a class template , parameterized (among others) on the character type it uses to represent the stored sequence. This is passed as the BaseType template type argument. There are 2 concrete template instantiations, CStringA and CStringW , that use char and wchar_t to store the sequence of characters, respectively ¹ .

CStringT exposes the following predefined types that describe the properties of the template instantiation:

• XCHAR : Character type used to store the sequence.
• YCHAR : Character type that an instance can be converted from/to.

The following table shows the concrete types for CStringA and CStringW :

         | XCHAR   | YCHAR
---------+---------+--------
CStringA | char    | wchar_t
CStringW | wchar_t | char

While the storage of the CStringT instantiations make no restrictions with respect to the character encoding being used, the conversion c'tors and operators are implemented based on the following assumptions:

• char represents ANSI ² encoded code units.
• whcar_t represents UTF-16 encoded code units.

If your program doesn't match those assumptions, it is strongly advised to disable implicit wide-to-narrow and narrow-to-wide conversions. To do this, defined the _CSTRING_DISABLE_NARROW_WIDE_CONVERSION preprocessor symbol prior to including any ATL/MFC header files. Doing so is recommended even if your program meets the assumptions to prevent accidental conversions, that are both costly as well as potentially destructive.

With that out of the way, let's move on to the questions:

Why are there two versions, one for const char* ( LPCSTR ) and one for unsigned char* ?

That's easy: Convenience. The overload simply allows you to construct a CString instance irrespective of the signedness of the character type ³ . The implementation of the overload taking a const unsigned char* argument 'forwards' to the c'tor taking a const char* :

CSTRING_EXPLICIT CStringT(_In_z_ const unsigned char* pszSrc) :
    CThisSimpleString( StringTraits::GetDefaultManager() )
{
    *this = reinterpret_cast< const char* >( pszSrc );
}

Which version should I use for different cases?

It doesn't matter, as long as you are constructing a CStringA , ie no conversion is applied. If you are constructing a CStringW , you shouldn't be using either of those (as explained above).

For example, does CStringT("Hello") use the first or second version?

"Hello" is of type const char[6] , that decays into a const char* to the first element in the array, when passed to the CString c'tor. It calls the overload taking a const char* argument.

When getting a null-terminated string from a third-party, such as sqlite3_column_text() ( see here ), should I convert it to char* or unsigned char * ? ie, should I use CString((LPCSTR)sqlite3_column_text(...)) or CString(sqlite3_column_text(...)) ?

SQLite assumes UTF-8 encoding in this case. CStringA can store UTF-8 encoded text, but it's really, really dangerous to do so. CStringA assumes ANSI encoding, and readers of your code likely will do, too. It is recommended to either change your SQLite database to store UTF-16 (and use sqlite_column_text16 ) to construct a CStringW . If that is not feasible, manually convert from UTF-8 to UTF-16 before storing the data in a CStringW instance using the CA2WEX macro:

CStringW data( CA2WEX( sqlite3_column_text(), CP_UTF8 ) );

It seems that both will work, is that right?

That's not correct. Neither one works as soon as you get non-ASCII characters from your database.

Why does the char* version construct a "Unicode" CStringT but the unsigned char* version will construct a CStringT ?

That looks to be the result of documentation trying to be compact. A CStringT is a class template. It is neither Unicode nor does it even exist. I'm guessing that remark section on the constructors is meant to highlight the ability to construct Unicode strings from ANSI input (and vice versa). This is briefly mentioned, too ( "Note that some of these constructors act as conversion functions." ).

To sum this up, here is a list of generic advice when using MFC/ATL strings:

• Prefer using CStringW . This is the only string type whose implied character encoding is unambiguous (UTF-16).
• Use CStringA only, when interfacing with legacy code. Make sure to unambiguously note the character encoding used. Also make sure to understand that "currently active locale" can change at any time. See Keep your eye on the code page: Is this string CP_ACP or UTF-8? for more information.
• Never use CString . Just by looking at code, it's no longer clear, what type this is (could be any of 2 types). Likewise, when looking at a constructor invocation, it is no longer possible to see, whether this is a copy or conversion operation.
• Disable implicit conversions for the CStringT class template instantiations.

---

¹ There's also CString that uses the generic-text mapping TCHAR as its BaseType . TCHAR expands to either char or wchar_t , depending preprocessor symbols. CString is thus an alias for either CStringA or CStringW depending on those very same preprocessor symbols. Unless you are targeting Win9x, don't use any of the generic-text mappings.

² Unlike Unicode encodings, ANSI is not a self-contained representation. Interpretation of code units depends on external state (the currently active locale). Do not use unless you are interfacing with legacy code.

³ It is implementation defined, whether char is interpreted as signed or unsigned. Either way, char , unsigned char , and signed char are 3 distinct types. By default, Visual Studio interprets char as signed.