Pourquoi existe-t-il des macros TEXT comme la même chose dans win32?

Je veux connaître la raison pour laquelle il existe des macros telles que T, TEXT, _TEXT, __TEXT ou __T quand elles finissent toutes par faire la même chose.

c’est à dire

mapper “ssortingng” à L “ssortingng” si UNICODE est défini.

Merci pour les réponses. Sur une approche plus pratique, quelqu’un peut-il m’expliquer le comportement du code ci-dessous?

#include  #include  #include  // For _T and _TEXT #include  // 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(); }

Mise à jour: Je pense que mon code a quelque chose à voir avec la tokenisation du préprocesseur C. Je publie une question distincte pour cela. Merci.

Comme c’est souvent le cas avec les choses “arcanes”, Raymond Chen donne quelques informations (emphase ajoutée):

Alors, quelles sont toutes ces différentes façons de dire la même chose? Il y a en fait une méthode derrière la folie.

Les versions simples sans le trait de soulignement affectent le jeu de caractères que les fichiers d’en-tête Windows traitent par défaut . Donc, si vous définissez UNICODE, GetWindowText sera mappé à GetWindowTextW au lieu de GetWindowTextA, par exemple. De même, la macro TEXT sera mappée à L “…” au lieu de “…”.

Les versions avec le trait de soulignement affectent le jeu de caractères que les fichiers d’en-tête d’exécution C sont traités par défaut . Donc, si vous définissez _UNICODE, alors _tcslen sera mappé sur wcslen au lieu de strlen, par exemple. De même, la macro _TEXT sera mappée sur L “…” au lieu de “…”. Qu’en est-il de _T? Ok, je ne sais pas pour celui-là. Peut-être que c’était juste pour sauver quelqu’un en train de taper.

Pour de nombreuses macros, il y en a une pour Win32 et une pour la bibliothèque d’exécution C. Cela expliquerait TEXT (Win32) et _TEXT (bibliothèque d’exécution C). Les versions à double soulignement sont probablement des macros d’aide non destinées à un usage général. Le T est probablement une commodité pour ceux qui pensent que le texte est trop long.

Le symbole UNICODE affecte les déclarations dans les en-têtes d’API Windows (principalement ), tandis que les symboles _UNICODE et _MBCS affectent les déclarations dans la bibliothèque C.

Exemple d’API Windows: avec UNICODE mappe MessageBox définie sur MessageBoxW , dans la terminologie Windows, la version Unicode , tandis que UNICODE non défini, MessageBox correspond à la version ANSI de MessageBoxA .

L’exemple de bibliothèque AC est plus impliqué.

Malgré deux symboles _UNICODE et _MBCS , seuls trois cas sont distingués:

Aucun d’entre eux n’a défini, et par exemple _tcslen correspond à strlen , la version à caractères étroits .
_MBCS défini et _UNICODE non défini, et par exemple _tcsclen correspond à _mbslen , la version multi-octets .
_UNICODE défini et _MBCS non défini, et par exemple _tcslen sur wcslen , la version à caractères larges .

Il convient de noter que tout cela était compatible avec Windows 9x, qui ne disposait pas d’une API à caractères larges.

Cependant, en 2001, Microsoft a introduit la couche pour Unicode , qui fournissait essentiellement une API à caractères larges pour Windows 9x. Et avec cela, tout le système ci-dessus était obsolète, sauf dans un cas, celui d’utiliser MFC en tant que DLL dans Windows 9x et de ne pouvoir ou ne pas vouloir le reconstruire. Eh bien, sauf que la personne qui gère la génération de code de Visual Studio n’a, à partir de la version 11, pas encore compris ce fait il y a dix ans, et qu’elle induit en erreur les hordes de débutants qui, en tant que professionnels, ce régime de gaspillage de temps non productif.

Cheers & hth.,

Assurer la compatibilité (en amont) et être compatible avec le code écrit pour d’autres plates-formes