O que a Microsoft está usando como tipo de dados para strings Unicode?

Question

Estou no processo de aprender C ++ e me deparei com um artigo sobre o MSDN aqui:

http://msdn.microsoft.com/en-us/magazine/dd861344.aspx

No primeiro exemplo de código, a única linha de código com a qual minha pergunta está relacionada é a seguinte:

VERIFY(SetWindowText(L"Direct2D Sample"));

Mais especificamente esse prefixo L. Eu tive um pouco de ler e me corrigir se estiver errado :-), mas isso é para permitir strings unicode, ou seja, preparar-se para um longo conjunto de personagens. Agora, durante a minha leitura, me deparei com outro artigo sobre técnicas adavnced strings em C aqui http://www.flipcode.com/archives/advanced_string_techniques_in_c-part_i_unicode.shtml

Ele diz que existem algumas opções, incluindo a inclusão do cabeçalho:

#define UNICODE 

OU

#define _UNICODE

Em C, aponte novamente se estou errado, aprecie seu feedback. Além disso, mostra o tipo de dados adequado para essas seqüências unicode:

wchar_t

Ele joga na mistura uma macro e uma espécie de tipo de dados híbridos, sendo a macro:

_TEXT(t)

que simplesmente prefixa a string com o tipo de dados L e híbrido como

TCHAR 

O que aponta permitirá o Unicode se o cabeçalho estiver lá e o ASCII, se não. Agora, minha pergunta é, ou mais uma curadora que eu gostaria de confirmar, a Microsoft usaria esse tipo de dados TCHAR que é mais flexível ou há algum benefício em se comprometer a usar o WCHAR_T.

Além disso, quando digo que a Microsoft usa isso, mais especificamente para exmaple nas bibliotecas ATL e WTL, alguém de si tem preferência ou tem alguns conselhos sobre isso?

Saúde,

Andrew

Answer 1

Para todos os novos softwares, você deve definir Unicode e usar WCHAR_T diretamente. Usar Ansi Stirngs voltará para assombrá -lo.

Você deve apenas usar o WCHAR_T e as versões amplas de todas as funções do CRT (ex: WCSCMP em vez do STRCMP). O texto macros e tchar etc apenas existem se o seu código precisar funcionar em ambientes ANSI e Unicode que eu sinto que o código raramente precisa fazer.

Quando você cria um novo aplicativo Windows usando o Visual Studio Unicode, é definido automaticamente e o WCHAR_T funcionará como um embutido.

Answer 2

Resposta curta: a infraestrutura híbrida com o TCHAR digite o _TEXT() macro e os vários _t* funções (_tcscpy vem à mente) são um retrocesso para os momentos em que a Microsoft tinha duas plataformas coexistindo:

1. A linha do Windows NT foi baseada na representação do Unicode String
2. A linha do Windows 95/98/ME foi baseada na representação da String ANSI.

Representação de string aqui significa que todas as APIs do Windows que esperavam ou retornavam a string ao seu aplicativo usavam uma ou outra representação para essas seqüências. Com acrescentou ainda mais confusão, pois estava disponível nas duas plataformas - e esperadas strings unicode em ambos!

Naqueles tempos antigos, foi incentivado que você escrevesse código "portátil": você foi instruído a usar a infraestrutura híbrida para suas strings, para que você possa compilar os dois modelos apenas definindo/indefinindo Unicode e/ou _unicode para o seu aplicativo.

Como a linha Windows9x não é mais relevante (para a grande maioria dos aplicativos de qualquer maneira), você pode ignorar com segurança o mundo ANSI e usar as cordas Unicode diretamente.

Cuidado, porém, que o Unicode possui várias representações hoje: como é apontado acima da Convenção Unicode implícita por WCHAR_T é a representação UCS-2 (todos os caracteres codificados em palavras de 16 bits). Existem outras representações amplamente usadas onde isso não é necessariamente verdadeiro.

Answer 3

No Windows, é WCHAR_T com a codificação UTF-16 (2 bytes).

Fonte : http://www.firstobject.com/wchar_t-tring-on-linux-osx-windows.htm

Answer 4

O TCHAR altera seu tipo dependendo se o Unicode for definido e deve ser usado quando você deseja o código que você pode compilar para Unicode e não-unicode.

Se você deseja processar apenas os dados Unicode explicitamente, sinta -se à vontade para usar o wchar_t.