为什么在win32中有相同的TEXT类似宏?

时间:2022-02-27 00:02:05

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.

我想知道为什么有一些宏,如T,TEXT,_TEXT,__TEXT或__T,当它们最终都做同样的事情时。

i.e.

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

如果定义了UNICODE,则将“string”映射到L“string”。

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.

更新:我认为我的代码与C预处理器标记化有关。我正在发布一个单独的问题。谢谢。

4 个解决方案

#1


12  

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 "...".

没有下划线的普通版本会影响Windows头文件视为默认值的字符集。因此,如果您定义UNICODE,那么GetWindowText将映射到GetWindowTextW而不是GetWindowTextA。类似地,TEXT宏将映射到L“...”而不是“...”。

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.

带有下划线的版本会影响C运行时头文件作为默认值处理的字符集。因此,如果您定义_UNICODE,那么_tcslen将映射到wcslen而不是strlen,例如。同样,_TEXT宏将映射到L“...”而不是“...”。 _T怎么样?好的,我不知道那一个。也许这只是为了节省一些打字的人。

#2


4  

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.

对于许多宏,有一个Win32和一个C运行时库。这将解释TEXT(Win32)和_TEXT(C运行时库)。双下划线版本可能是不适用于一般用途的辅助宏。对于那些认为TEXT太长的人来说,T可能是一种便利。

#3


3  

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.

UNICODE符号影响Windows API标头中的声明(主要是 ),而_UNICODE和_MBCS符号会影响C库中的声明。

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.

Windows API示例:使用UNICODE定义MessageBox映射到MessageBoxW,在Windows术语中使用Unicode版本,而使用UNICODE未定义的MessageBox映射到MessageBoxA,ANSI版本。

A C library example is more involved.

更多涉及C库示例。

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

尽管有两个符号_UNICODE和_MBCS,但只有三种情况可以区分:

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

    它们都没有定义,例如_tcslen映射到strlen,即窄字符版本。

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

    _MBCS已定义且_UNICODE未定义,例如_tcsclen映射到_mbslen,即多字节字符版本。

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

    定义_UNICODE并且未定义_MBCS,例如_tcslen映射到wcslen,宽字符版本。

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

值得注意的是,所有这些东西都支持Windows 9x,它没有广泛的字符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.

但是,在2001年,微软推出了Layer for Unicode,它基本上为Windows 9x提供了一个宽字符API。除此之外,上面的整个方案已经过时,除了一个案例,即在Windows 9x中使用MFC作为DLL,并且无法或不愿意重建它。好吧,除了那个维护Visual Studio代码生成的人,从版本11开始,还没有找到十年前的事实,并且这反过来误导成群的新手,然后专业人士严重不愿意停止使用这个非生产性的时间浪费计划。

Cheers & hth.,

干杯&hth。,

#4


0  

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

提供(向后)兼容性并与为其他平台编写的代码兼容

#1


12  

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 "...".

没有下划线的普通版本会影响Windows头文件视为默认值的字符集。因此,如果您定义UNICODE,那么GetWindowText将映射到GetWindowTextW而不是GetWindowTextA。类似地,TEXT宏将映射到L“...”而不是“...”。

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.

带有下划线的版本会影响C运行时头文件作为默认值处理的字符集。因此,如果您定义_UNICODE,那么_tcslen将映射到wcslen而不是strlen,例如。同样,_TEXT宏将映射到L“...”而不是“...”。 _T怎么样?好的,我不知道那一个。也许这只是为了节省一些打字的人。

#2


4  

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.

对于许多宏,有一个Win32和一个C运行时库。这将解释TEXT(Win32)和_TEXT(C运行时库)。双下划线版本可能是不适用于一般用途的辅助宏。对于那些认为TEXT太长的人来说,T可能是一种便利。

#3


3  

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.

UNICODE符号影响Windows API标头中的声明(主要是 ),而_UNICODE和_MBCS符号会影响C库中的声明。

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.

Windows API示例:使用UNICODE定义MessageBox映射到MessageBoxW,在Windows术语中使用Unicode版本,而使用UNICODE未定义的MessageBox映射到MessageBoxA,ANSI版本。

A C library example is more involved.

更多涉及C库示例。

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

尽管有两个符号_UNICODE和_MBCS,但只有三种情况可以区分:

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

    它们都没有定义,例如_tcslen映射到strlen,即窄字符版本。

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

    _MBCS已定义且_UNICODE未定义,例如_tcsclen映射到_mbslen,即多字节字符版本。

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

    定义_UNICODE并且未定义_MBCS,例如_tcslen映射到wcslen,宽字符版本。

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

值得注意的是,所有这些东西都支持Windows 9x,它没有广泛的字符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.

但是,在2001年,微软推出了Layer for Unicode,它基本上为Windows 9x提供了一个宽字符API。除此之外,上面的整个方案已经过时,除了一个案例,即在Windows 9x中使用MFC作为DLL,并且无法或不愿意重建它。好吧,除了那个维护Visual Studio代码生成的人,从版本11开始,还没有找到十年前的事实,并且这反过来误导成群的新手,然后专业人士严重不愿意停止使用这个非生产性的时间浪费计划。

Cheers & hth.,

干杯&hth。,

#4


0  

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

提供(向后)兼容性并与为其他平台编写的代码兼容