我想知道为什么会有像T、TEXT、_TEXT、__TEXT或__T这样的宏，而它们最终都做同样的事情。
即
如果定义了UNICODE，则将“string”Map到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预处理器标记化有关。我正在发布一个单独的问题。谢谢。
4条答案
按热度按时间wn9m85ua1#
就像“《双城之战》”事物的情况一样，Raymond Chen gives some information（着重号是后加的）：
那么，为什么会有这么多不同的说法呢？疯狂的背后其实是有方法的。
不带下划线的普通版本会影响Windows头文件视为默认的字符集。因此，如果您定义
UNICODE，则GetWindowText将Map到GetWindowTextW而不是GetWindowTextA。同样，TEXT宏将Map到L"..."而不是"..."。带下划线的版本会影响C运行时头文件视为默认的字符集。例如，如果您定义
_UNICODE，则_tcslen将Map到wcslen而不是strlen。同样，_TEXT宏将Map到L"..."而不是"..."。_T呢？好的，我不知道那个。也许只是为了保存点打字的时间。zphenhs42#
对于许多宏，有Win32宏和C运行时库宏。这可以解释TEXT（Win32）和_TEXT（C运行时库）。双下划线版本可能是不适合一般用途的辅助宏。T可能是那些认为TEXT太长的人的方便。
tyky79it3#
UNICODE符号影响Windows API头文件中的声明（主要是<windows.h>），而_UNICODE和_MBCS符号影响C库中的声明。Windows API示例：使用
UNICODE定义的MessageBoxMap到MessageBoxW，在Windows术语中为 *Unicode版本 *，而使用UNICODE未定义的MessageBoxMap到MessageBoxA，为 *ANSI版本 *。一个C库的例子是比较复杂的。
尽管有两个符号
_UNICODE和_MBCS，但只有三种情况是可以区分的：_tcslenMap到strlen，* 窄字符版本 *。_MBCS已定义，_UNICODE未定义，例如_tcsclenMap到_mbslen，* 多字节字符版本 *。_UNICODE已定义，_MBCS未定义，例如_tcslenMap到wcslen，* 宽字符版本 *。值得注意的是，所有这些都是为了支持Windows 9x，而Windows 9x没有宽字符API。
然而，在2001年，微软引入了Layer for Unicode，它本质上为Windows 9x提供了一个宽字符API。有了它，上面的整个方案都被淘汰了，除了一种情况，在Windows 9x中使用MFC作为DLL，并且不能或不愿意重建它。好吧，也除了维护Visual Studio代码生成的人，从版本11开始，然而，这并没有抓住十年前的事实，这反过来又误导了成群的新手，他们作为专业人士是严重不愿意停止使用这种非生产性的浪费时间的计划。
zaqlnxep4#
提供（向后）兼容性，并与为其他平台编写的代码兼容