Should I use _T or _TEXT on C++ string literals?

For example:

// This will become either SomeMethodA or SomeMethodW,
// depending on whether _UNICODE is defined.
SomeMethod( _T( "My String Literal" ) );

// Becomes either AnotherMethodA or AnotherMethodW.
AnotherMethod( _TEXT( "My Text" ) );

I've seen both. _T seems to be for brevity and _TEXT for clarity. Is this merely a su开发者_运维百科bjective programmer preference or is it more technical than that? For instance, if I use one over the other, will my code not compile against a particular system or some older version of a header file?

---

A simple grep of the SDK shows us that the answer is that it doesn't matter—they are the same. They both turn into __T(x).

C:\...\Visual Studio 8\VC>findstr /spin /c:"#define _T(" *.h 
crt\src\tchar.h:2439:#define _T(x)       __T(x) 
include\tchar.h:2390:#define _T(x)       __T(x)

C:\...\Visual Studio 8\VC>findstr /spin /c:"#define _TEXT(" *.h 
crt\src\tchar.h:2440:#define _TEXT(x)    __T(x) 
include\tchar.h:2391:#define _TEXT(x)    __T(x)

And for completeness:

C:\...\Visual Studio 8\VC>findstr /spin /c:"#define __T(" *.h 
crt\src\tchar.h:210:#define __T(x)     L ## x 
crt\src\tchar.h:889:#define __T(x)      x 
include\tchar.h:210:#define __T(x)     L ## x 
include\tchar.h:858:#define __T(x)      x

However, technically, for C++ you should be using TEXT() instead of _TEXT(), but it (eventually) expands to the same thing too.

---

Commit to Unicode and just use L"My String Literal".

---

From Raymond Chen:

TEXT vs. _TEXT vs. _T, and UNICODE vs. _UNICODE

The plain versions without the underscore affect the character set the Windows header files treat as default. So if you define UNICODE, then GetWindowText will map to GetWindowTextW instead of GetWindowTextA, for example. Similarly, the TEXT macro will map to L"..." instead of "...".

The versions with the underscore affect the character set the C runtime header files treat as default. So if you define _UNICODE, then _tcslen will map to wcslen instead of strlen, for example. Similarly, the _TEXT macro will map to L"..." instead of "...".

What about _T? Okay, I don't know about that one. Maybe it was just to save somebody some typing.

Short version: _T() is a lazy man's _TEXT()

Note: You need to be aware of what code-page your source code text editor is using when you write:

_TEXT("Some string containing Çontaining");
TEXT("€xtended characters.");

The bytes the compiler sees depends on the code page of your editor.

---

Here's an interesting read from a well-known and respected source.

Similarly, the _TEXT macro will map to L"..." instead of "...".

What about _T? Okay, I don't know about that one. Maybe it was just to save somebody some typing.

---

These macros are a hold over from the days when an application might have actually wanted to compile both a unicode and ANSI version.

There is no reason to do this today - this is all vestigial. Microsoft is stuck with supporting every possible configuration forever, but you aren't. If you are not compiling to both ANSI and Unicode (and no one is, let's be honest) just go to with L"text".

And yes, in case it wasn't clear by now: _T == _TEXT

---

I've never seen anyone use _TEXT() instead of _T().

---

Neither. In my experience there are two basic types of string literals, those that are invariant, and those that need to be translated when your code is localized.

It's important to distinguish between the two as you write the code so you don't have to come back and figure out which is which later.

So I use _UT() for untranslatable strings, and ZZT() (or something else that is easy to search on) for strings that will need to be translated. Instances of _T() or _TEXT() in the code are evidence of string literals that have not yet be correctly categorized.

_UT and ZZT are both #defined to _TEXT

---

Use neither, and also please don't use the L"..." crap. Use UTF-8 for all strings, and convert them just before passing to microsoft APIs.