Devo usar _t ou _text em literais de string c ++?
-
20-09-2019 - |
Pergunta
Por exemplo:
// This will become either SomeMethodA or SomeMethodW,
// depending on whether _UNICODE is defined.
SomeMethod( _T( "My String Literal" ) );
// Becomes either AnotherMethodA or AnotherMethodW.
AnotherMethod( _TEXT( "My Text" ) );
Eu vi os dois. _T parece ser por brevidade e _text para maior clareza. Isso é apenas uma preferência subjetiva do programador ou é mais técnico do que isso? Por exemplo, se eu usar um sobre o outro, meu código não compilará contra um sistema específico ou alguma versão mais antiga de um arquivo de cabeçalho?
Solução
Um simples grep do SDK nos mostra que a resposta é que não importa - eles são os mesmos. Ambos se transformam em __T(x)
.
C:\...\Visual Studio 8\VC>findstr /spin /c:"#define _T(" *.h crt\src\tchar.h:2439:#define _T(x) __T(x) include\tchar.h:2390:#define _T(x) __T(x) C:\...\Visual Studio 8\VC>findstr /spin /c:"#define _TEXT(" *.h crt\src\tchar.h:2440:#define _TEXT(x) __T(x) include\tchar.h:2391:#define _TEXT(x) __T(x)
E para completar:
C:\...\Visual Studio 8\VC>findstr /spin /c:"#define __T(" *.h crt\src\tchar.h:210:#define __T(x) L ## x crt\src\tchar.h:889:#define __T(x) x include\tchar.h:210:#define __T(x) L ## x include\tchar.h:858:#define __T(x) x
No entanto, tecnicamente, para C ++ você deve estar usando TEXT()
ao invés de _TEXT()
, mas (eventualmente) se expande para a mesma coisa também.
Outras dicas
Comprometa -se com unicode e apenas use L"My String Literal"
.
A partir de Raymond Chen:
Texto vs. _text vs. _t, e unicode vs. _unicode
As versões simples sem o sublinhamento afetam o caractere definido que os arquivos do cabeçalho do Windows tratam como padrão. Portanto, se você definir o Unicode, o getWindowText mapeará para getWindowTextw em vez do getWindowTexta, por exemplo. Da mesma forma, a macro de texto mapeará para L "..." em vez de "...".
As versões com o sublinhado afetam o caractere definido os arquivos de cabeçalho do tempo de execução C tratam como padrão. Portanto, se você definir _unicode, então _tcslen mapeará para o WCSLEN em vez de Strlen, por exemplo. Da mesma forma, a macro _text mapeará para L "..." em vez de "...".
Que tal _t? Ok, eu não sei sobre isso. Talvez fosse apenas para salvar alguém de digitação.
Versão curta: _T()
é um homem preguiçoso _TEXT()
NOTA: Você precisa estar ciente de qual código o seu código de texto do código-fonte o editor está usando quando você escreve:
_TEXT("Some string containing Çontaining");
TEXT("€xtended characters.");
Os bytes que o compilador vê depende da página de código do seu editor.
Aquié uma leitura interessante de uma fonte bem conhecida e respeitada.
Da mesma forma, a macro _text mapeará para L "..." em vez de "...".
Que tal _t? Ok, eu não sei sobre isso. Talvez fosse apenas para salvar alguém de digitação.
Eu nunca vi alguém usar _TEXT()
ao invés de _T()
.
Nenhum. Na minha experiência, existem dois tipos básicos de literais de cordas, aqueles que são invariantes e aqueles que precisam ser traduzidos quando seu código estiver localizado.
É importante distinguir entre os dois enquanto você escreve o código para não precisar voltar e descobrir qual é qual posterior.
Então eu uso _UT()
para seqüências não traduzíveis, e ZZT()
(ou algo mais fácil de pesquisar) por strings que precisarão ser traduzidas. Instâncias de _T()
ou _TEXT()
No Código, há evidências de literais de string que ainda não foram categorizados corretamente.
_UT
e ZZT
ambos são #decididos para _text
Essas macros são uma retenção dos dias em que um aplicativo pode realmente desejar compilar uma versão Unicode e ANSI.
Não há razão para fazer isso hoje - tudo isso é vestigial. A Microsoft está presa em apoiar todas as configurações possíveis para sempre, mas você não está. Se você não está compilando o ANSI e o Unicode (e ninguém é, vamos ser honestos), basta ir com L "texto".
E sim, caso não esteja claro até agora: _t == _text
Não use nenhum e também não use a porcaria L "...". Use o UTF-8 para todas as cordas e converta-as antes de passar para as APIs da Microsoft.