Starting a new Windows app: Should I use _TCHAR or wchar_t for text?

Question

I\'m coding up a new (personal hobby) app for Windows in c++.

In previous low-level Windows stuff I\'ve used _TCHAR (or just TCHAR) arrays/basic_strings

Answer 1

wchar_t is a c++ defined type, that is 16 bits in Visual Studio, but is 32bits in various gcc compilers. Its always capable of holding a unicode codepoint.

TCHAR and _TCHAR are not "unicode" characters - theyre meant to be used in code that may be compiled and/or used in Unicode OR Ansi programs:

_TCHAR is - from its leading underscore - a Microsoft C runtime library "extension" to the c++ standard. _TCHAR will, when _UNICODE is defined, be a 16bit character, when _MBCS is defined, be a multibyte character, and when neither is defined, be a singlebyte character. Use this type if you use MS CRT defined string functions that are prefixed with _t: _tcscpy() for example is the replacement for strcpy()/wcscpy().

TCHAR is a defined by the Win32 API. This type is a CHAR when UNICODE is not defined, and a WCHAR when UNICODE is defined (note the lack of an underscore on this type). Windows API functions that take strings likewise expect WCHAR strings in UNICODE builds and CHAR strings in non unicode builds.

To summarize:

• wchar_t is a cross platform c++ defined type that can hold a unicode code point - on compilers other than Microsoft, is frequently 32bits wide.
• _TCHAR is a microsoft defined type that is paired with _tcs* c runtime functions that changes its type based on the definition of _UNICODE and/or _MBCS.
• TCHAR is a Windows API defined type that changes its type based on the definition (or not) of UNICODE.
• WCHAR is the native Windows API type for dealing with unicode strings. When using a GCC toolset to build windows code, this will be 16bits wide where wchar_t might not.

Does that help? I don't know.

Answer 2

If you always compile your app for Unicode while you are developing it, IT WILL NOT WORK when compiled for ANSI strings, even if it is crammed full of TCHARs. (Toy apps excepted.)

That's what JaredPar was getting at when he said ANSI is not a valid target. If you want to maintain Unicode and ANSI versions, you can use TCHAR to do that, but just using TCHAR and other T's won't get you there - you have to actively build and maintain both versions. Definitely not worth it anymore for most apps.

Answer 3

Use TCHAR. It opens your application for both UNICODE and non UNICODE deployment scenarions. Of course there is more pain with string converstions and usage of standard string manipulation functions.

Answer 4

No there is not. Just go with wchar_t.

TCHAR is only useful if you want to be able to use a conditional compilation switch to convert your program to operate in ASCII mode. Since Win2K and up are unicode platforms this switch does not provide any value. You'd instead be implying to other developers in your project that ASCII was a valid target when in fact it's not.

Answer 5

I'd go with plain wchar_t

The advantage to TCHAR is that it allows you to toggle Unicode on and off and your code accessing the Windows API will keep working.

The problem with it is that no other API will accept it.

std::cout will choke on a std::wstring,std::string will choke on being initialized with a wchar_t* and so on.

From the point of view of every other library, you should use either char or wchar_t, and switching between them is nontrivial.

And since non-Unicode compatibility was only really an issue in Windows 95, there's really no point in supporting both any more. Enable Unicode, use wchar_t and save yourself the headaches.

OF course, to avoid confusion then, you might also want to call the *W versions of Win32 functions. Instead of CreateWindow, CreateWindowW, for example, so that even if someone compiles your code with Unicode disabled in the project settings, the code will still work. If you're going to hardcode for Unicode support, you might as well do so consistently.