CODEWITHSUNDEEP
c++windowswinapi
sg1
sg1

Reputation: 485

Why are there different TEXT like macros for the same thing in win32?

I want to know the reason why there are macros such as T, TEXT, _TEXT, __TEXT or __T when they all ultimately do the same thing.

i.e.

mapping "string" to L"string" if UNICODE is defined.

Thanks for the answers. On a more practical approach, can somebody explain me the behavior of the code given below?

#include <stdio.h>
#include <conio.h>
#include <tchar.h>   // For _T and _TEXT
#include <windows.h> // For __TEXT 

int __cdecl main ()

{

  printf ("%s", _TEXT(__FILE__ ));  // Works fine

  printf ("%s", _T(__FILE__));      // Works fine

  printf ("%s", __TEXT(__FILE__ )); // error C2065: 'L__FILE__': undeclared identifier

  _getwch();

}

Update: I think my code has something to do with C preprocessor tokenization. I am posting a separate question for that. Thanks.

Upvotes: 9

Views: 4402

Answers (4)

Christian.K
Christian.K

Reputation: 49260

As it is often the case with "arcane" things, Raymond Chen gives some information (emphasis added):

So what's with all these different ways of saying the same thing? There's actually a method behind the madness.

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.

Upvotes: 18

Cheers and hth. - Alf
Cheers and hth. - Alf

Reputation: 145269

The UNICODE symbol affects the declarations in Windows API headers (primarily <windows.h>), while the _UNICODE and _MBCS symbols affect the declarations in the C library.

Windows API example: with UNICODE defined MessageBox maps to MessageBoxW, in Windows terminology the Unicode version, while with UNICODE undefined MessageBox maps to MessageBoxA, the ANSI version.

A C library example is more involved.

In spite of two symbols _UNICODE and _MBCS there are just three cases that are distinguished:

  • None of them defined, and e.g. _tcslen maps to strlen, the narrow character version.

  • _MBCS defined and _UNICODE not defined, and e.g. _tcsclen maps to _mbslen, the multi-byte character version.

  • _UNICODE defined and _MBCS not defined, and e.g. _tcslen maps to wcslen, the wide character version.

It's worth noting that all this stuff was in support of Windows 9x, which did not have a wide character API.

However, in 2001 Microsoft introduced the Layer for Unicode, which essentially provided a wide character API for Windows 9x. And with that, the whole scheme above was obsoleted except for one case, that of using MFC as DLLs in Windows 9x, and being unable or unwilling to rebuild it. Well, also except that whoever maintains Visual Studio's code generation has, as of version 11, not yet caught on to that fact of ten years ago, and that this in turn misleads hordes of newbies, who then as professionals are seriously unwilling to stop using this non-productive time wasting scheme.

Upvotes: 4

Adrian McCarthy
Adrian McCarthy

Reputation: 47962

For many macros, there is the Win32 one and the one for the C run-time library. That would explain TEXT (Win32) and _TEXT (C run-time library). The double-underscore versions are probably helper macros not intended for general use. The T is probably a convenience for those who think TEXT is too long.

Upvotes: 5

bert-jan
bert-jan

Reputation: 968

To provide (backward) compatibility and to be compatible with code written for other platforms

Upvotes: 0

Related Questions