static TCHAR szWindowClass[] = L"foo";
L is "glued" to the string "foo". How come? A function or a macro as I am used to is something like L("foo");Can anyone explain me how come L be glued to the string?
6 Réponses :
Au fait, si vous utilisez l code> n'est pas une macro, ce n'est que le préfixe standard pour large ( wchar_t code>, "Unicode") littéraux de chaînes; Le concept est similaire au suffixe l code> pour LONG INT code> littéraux, f code> suffixe pour float code> littéraux et ainsi de suite sur < sup> 1 sup>. p>
TCHAR code> s, vous ne devriez pas utiliser l code> directement; au lieu de cela, vous devez utiliser le _t () code> ou texte () code> macro, qui ajoute l code> au début du littéral si l'application est compilée. "pour Unicode" (c.-à-d. TCHAR code> est défini comme wcharner code>) ou n'ajoute rien si la cible de compilation est "ANSI" ( TCHAR code> défini comme < Code> Char code>). P>
Que dois-je utiliser le long de L, au lieu de TCHAR?
@Fabricio: du cheval Bouche: wchar_t code> ou plutôt, wcharner code> (Pour éviter toute confusion avec Unix wchar_t code>, qui est un type de 32 bits). Notez les commentaires sous cet article et les commentaires sous ma réponse.
@Matteo: est i> une telle chose qu'une chose comme un wchar_t code> typef, ou est-ce une faute de cas?
@DevSolar: désolé, je voulais dire wcharner code>, le Winapi Typedef.
"Pourquoi suffixe pour les types d'arithmétiques et un préfixe pour des littéraux stricts" A: simplifier la tokénisation et le rendre rapide.
@Adrianmccarthy: Cela montre vraiment qu'il y a trois ans, je n'ai jamais fait de sérieux analyses, il était évident que c'était évident =) Cependant, dans ce cas particulier, je ne pense pas que cela changeait beaucoup, IIRC la grammaire pour des chaînes larges et étroites est la identique, le seul véritable avantage de savoir à partir de savoir quel type de chaîne peut être de le coder à WCHAR_T tout en lisant au lieu d'attendre jusqu'à ce que la fin de la chaîne sache si elle nécessite un traitement supplémentaire (et comment doit-il être signalé dans l'AST ).
Ce n'est pas une macro, c'est un jeton que le compilateur reconnaît comme préfixe qui a une signification particulière. P>
La même chose arrive avec ex. l code> en tant que suffixe qui produit LONG code> littéraux, comme dans long x = 42L; code>. P>.
Cette réponse est la seule qui dit "le compilateur reconnaît" explicitement.
Ce n'est pas une macro, tout comme sur un Sidenote, ce n'est pas si bien défini ce que signifie exactement une "chaîne large" est em>, donc ce n'est pas portable. Sauf si vous avez em> utiliser TCHAR / Conseil personnel: N'utilisez pas UTF-16. La plupart des gens ne le comprennent pas vraiment, comme en témoignent cet argument très sur les cordes "larges". ; -) p> 42UL code> n'est pas une macro: il indique au compilateur que "FOO" est une chaîne for forte> "forte>. p>
L "FOO" CODE> pour des raisons API, vous êtes probablement mieux à l'aide de la prise en charge de C ++ 11 Unicode (si la prise en charge de C ++ 11 est disponible. à vous): u8 "foo" code> (utf-8) ou u "foo" code> (utf-32), plus les types de chaîne / matrice appropriés. P>
D'autre part, si vous travaillez avec le Winapis, il est habituel d'utiliser des chaînes de largeur UTF-16 "pour bien jouer avec le reste de la plate-forme.
C'est exactement mon point: Winapi n'est pas UTF-16, ils disent simplement qu'ils sont. (UTF-16 est un codage multibyte, pas un codage large.) Une fois que vous quittez le BMP, les choses deviennent "drôles" avec Winapi. ;-) Reformulé un peu pour le rendre plus clair.
Oui, c'est un état de choses triste; Il a commencé comme UCS-2 quand il n'y avait rien d'autre que le BMP et a été converti "en quelque sorte" dans UTF-16 autour de Windows 2000, ce qui est probablement le pire de tous les codages. D'autre part, l'interface "officielle" est (devrait être) UTF-16 (les versions -A code> sont des wrappers) et plusieurs nouvelles API n'existent que dans le w code> Version, donc il n'y a pas beaucoup de choix, même si vous conservez tout UTF-8 ou UTF-32 à l'intérieur lorsque vous devez appeler l'OS API, vous devez vous rendre à UTF-16. ... Et si certaines API sont cassées à l'extérieur du BMP, nous ne pouvons pas faire beaucoup ...: P
C'est pourquoi j'ai réaffirmé ma réponse un peu à «avoir à utiliser TCHAR pour des raisons d'API». Je travaille avec divers codages Unicode sur une base quotidienne et je suis triste de voir combien de programmeurs i> obtenir UTF-16 / UCS-2 mal ...
@Matteoitalia et postérité: le problème est le Une imprécision terrible de Microsoft quand on parle de ces questions . (Unicode n'est pas un codage de caractères, les caractères UTF-16 ne sont pas "larges", ni Windows ' wchar_t code>.) C'est un champ de mines terrible et terrible, et si vous pouvez peut i > Tu ferais mieux d'éviter tout ça. TCHAR CODE>, Incidemment, est probablement le pire de tout cela, car il peut s'agir de ce ou i> en fonction des paramètres du compilateur ...
Juste pour éviter les malentendus, en «évitant tout autant», j'étais, bien sûr, faisant appel à l'UTF-8 «clairement multibyte» et à l'UTF-32 «clairement large» comme options - non, par hasard, à la "clairement inadéquate" Codages ASCII / ISO. ;-)
@DevSolar - Devrais-je utiliser U8 le long de WCHAR? WCHAR S = U8 "FOO"; CODE> Edit: Mais il dit 'U8' non déclaré (première utilisation dans cette fonction) code>
@Fabricio: Non. Ce que je voulais dire, c'est que si vous pouvez vous en tirer, ne touchez pas l'API Windows (WRCHAR, TCHAR, etc.) du tout i> et utilisez ce que le c ++ 11 Standard fournit. Cependant, 1) Lorsque vous êtes sous Windows, il y a des chances que vous ne pouvez pas i> s'en sortir; et 2) vous n'en savez pas encore assez sur Unicode. ;-) (ce serait char8_t s = code> u8 "foo" `...)
@DevSolar: Dans les versions modernes de Windows, Winapi est absolument utf-16. Les paires de substituts travaillent juste bien. Il est vrai que lorsque Windows a commencé à migrer vers des personnages "larges", il était à peu près limité à UCS-2 et au BMP, mais c'était long, il y a longtemps.
@AdrianMcCarthy: Avec l'état de la documentation de la SP, il est difficile de dire la différence. Mais bon de savoir que c'est Devrait I> être bon à utiliser.
Et ça? P>
#Ifdef _unicode code> p>
#define l (str) l ## str code> p>
#else code> p>
#define l (str) str code> p>
#endif code> p>
Améliorez-le basé sur @Doo Hyeok Kim
#define DIAG "diag"
// innerally macro
#define __W(quote_string) L ## quote_string
// robust macro
#define _W(quoted_string_or_defined_string) __W(quoted_string_or_defined_string)
//std::wcout << _W(DIAG) << ", " << _W("_W(\"diag2\")") << ", " << __W("__W(\"diag3\")") <<std::endl;
en retard à cette question, mais cela m'a buggé il y a des années. Voici un lien vers une documentation donnant la définition de l plus d'autres.
CPPreference .com chaîne littéral p> aussi un article wikipedia sur Nouveaux littéraux à chaîne P> P>
Ceci est la fonction de compilateur / syntaxe.