Question

我想知道为什么存在诸如T，TEXT，_TEXT，__TEXT或__T之类的宏的原因，当它们最终都做同样的事情时。

即

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

感谢您的回答。在更实际的方法中，有人可以向我解释下面给出的代码的行为吗？

#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();

}

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

Answer 1

由于经常出现“神秘”的事情，Raymond Chen gives some information（重点补充）：

那么所有这些不同的说法方式是什么呢？   实际上有一种疯狂背后的方法。

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

带有下划线的版本会影响字符集   C运行时头文件视为默认。所以如果你定义_UNICODE，   然后_tcslen将映射到wcslen而不是strlen，例如。   同样，_TEXT宏将映射到L“...”而不是“...”。什么   关于_T？好的，我不知道那一个。也许只是为了节省   有人在打字。

Answer 2

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

Answer 3

UNICODE符号会影响Windows API标头中的声明（主要是<windows.h>），而_UNICODE和_MBCS符号会影响C库中的声明。

Windows API示例：UNICODE已定义MessageBox映射到MessageBoxW，在Windows术语中为 Unicode版本，而UNICODE未定义{ {1}}映射到MessageBox， ANSI版本。

更多涉及C库示例。

尽管有两个符号MessageBoxA和_UNICODE，但只有三种情况可以区分：

它们都没有定义，例如_MBCS映射到_tcslen，窄字符版本。
strlen已定义且_MBCS未定义，例如_UNICODE映射到_tcsclen，多字节字符版本。
_mbslen已定义且_UNICODE未定义，例如_MBCS映射到_tcslen，广角色版。

值得注意的是，所有这些东西都支持Windows 9x，它没有广泛的字符API。

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

干杯＆amp;第h。，

Answer 4

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

为什么在win32中对于同一个东西有不同的TEXT像宏？

4 个答案: