Почему в win32 есть разные TEXT, такие как макросы для одной и той же вещи?

Question

Я хочу знать причину, по которой существуют макросы, такие как T, TEXT, _TEXT, __TEXT или __T, когда все они в конечном итоге делают одно и то же.

т.е.L "строка", если определен UNICODE.

Спасибо за ответы.При более практическом подходе кто-нибудь может объяснить мне поведение приведенного ниже кода?

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

}

Обновление: я думаю, что мой код как-то связан с токенизацией препроцессора Си.Я публикую отдельный вопрос для этого.Благодаря.

Answer 1

Как это часто бывает с «тайными» вещами, Раймонд Чен дает некоторую информацию (выделение добавлено):

Так, что со всеми этими различными способами сказать то же самое? На самом деле за этим безумием стоит метод.

Простые версии без подчеркивания влияют на набор символов Заголовочные файлы Windows рассматриваются по умолчанию . Так что если вы определяете UNICODE, то GetWindowText будет отображаться в GetWindowTextW вместо GetWindowTextA, например. Точно так же макрос TEXT будет отображаться в L "..." вместо "...".

Версии с подчеркиванием влияют на набор символов Файлы заголовка среды выполнения C обрабатываются по умолчанию . Так что, если вы определите _UNICODE, тогда _tcslen будет отображаться в wcslen вместо strlen, например. Точно так же макрос _TEXT будет отображаться в L "..." вместо "...". Какие о _T? Хорошо, я не знаю об этом. Может быть, это было просто, чтобы спасти кто-то печатает.

Answer 2

Для многих макросов есть Win32 и библиотека времени выполнения C.Это объясняет TEXT (Win32) и _TEXT (библиотека времени выполнения C).Версии с двойным подчеркиванием, вероятно, являются вспомогательными макросами, не предназначенными для общего использования.Т, вероятно, удобство для тех, кто считает, что текст слишком длинный.

Answer 3

Символ UNICODE влияет на объявления в заголовках Windows API (в основном <windows.h>), в то время как символы _UNICODE и _MBCS влияют на объявления в библиотеке C.

Пример Windows API: с UNICODE определено MessageBox отображается на MessageBoxW, в терминологии Windows Unicode версия , в то время как с UNICODE undefined MessageBox отображается на MessageBoxA, Версия ANSI .

Пример библиотеки C более сложный.

Несмотря на два символа _UNICODE и _MBCS, различаются только три случая:

• Ни один из них не определен, и, например, _tcslen отображается на strlen, версия для узких символов .

• _MBCS определено и _UNICODE не определено, и, например, _tcsclen отображается на _mbslen, версия многобайтовых символов .

• _UNICODE определено и _MBCS не определено, и, например, _tcslen отображается на wcslen, версия для широких символов .

Стоит отметить, что все это было в поддержке Windows 9x, у которой не было API для широких символов.

Однако в 2001 году Microsoft представила Layer для Unicode , который, по сути, предоставил API для широких символов для Windows 9x. При этом вся вышеприведенная схема была устаревшей, за исключением одного случая - использования MFC в качестве DLL в Windows 9x и невозможности или нежелания ее перестраивать. Ну, кроме того, что тот, кто поддерживает генерацию кода в Visual Studio, начиная с версии 11, еще не осознал этого факта десять лет назад, и это, в свою очередь, вводит в заблуждение орды новичков, которые тогда, как профессионалы, серьезно не желают прекращать использовать эта непроизводительная трата времени.

Приветствия и hth.,

Answer 4

Для обеспечения (обратной) совместимости и совместимости с кодом, написанным для других платформ