O TCHAR ainda é relevante?

Eu sou novo na programação do Windows e depois de ler o livro Petzold eu me pergunto:

ainda é uma boa prática usar o tipo TCHAR ea function _T() para declarar cadeias ou se eu deveria apenas usar as cadeias L"" wchar_t e L"" em um novo código?

Vou segmentar apenas o Windows 2000 e o meu código será i18n desde o início.

Eu ainda usaria a syntax do TCHAR se estivesse fazendo um novo projeto hoje. Não há muita diferença prática entre usá-lo e a syntax WCHAR, e eu prefiro o código que é explícito em qual é o tipo de caractere. Como a maioria das funções da API e objects auxiliares usam / usam os tipos TCHAR (por exemplo: CString), faz sentido usá-los. Além disso, oferece flexibilidade se você decidir usar o código em um aplicativo ASCII em algum momento, ou se o Windows evoluir para Unicode32, etc.

Se você decidir ir a rota WCHAR, eu seria explícito sobre isso. Ou seja, use CStringW em vez de CString e converta macros ao converter para TCHAR (por exemplo: CW2CT).

Essa é a minha opinião, de qualquer maneira.

A resposta curta: NÃO .

Como todos os outros já escreveram, muitos programadores ainda usam TCHARs e as funções correspondentes. Na minha humilde opinião, todo o conceito foi uma má ideia . O processamento de string UTF-16 é muito diferente do processamento simples de string ASCII / MBCS. Se você usar os mesmos algoritmos / funções com ambos (isto é o que a idéia do TCHAR é baseada!), Você terá um desempenho muito ruim na versão UTF-16 se você estiver fazendo um pouco mais que simples concatenação de strings (como análise etc.). A principal razão é substitutos .

Com a única exceção, quando você realmente precisa compilar seu aplicativo para um sistema que não suporta Unicode, não vejo razão para usar essa bagagem do passado em um novo aplicativo.

Eu tenho que concordar com o Sascha. A premissa subjacente de TCHAR / _T() / etc. é que você pode escrever um aplicativo baseado em “ANSI” e, em seguida, magicamente dar suporte a Unicode definindo uma macro. Mas isso é baseado em várias suposições ruins:

Que você crie ativamente as versões MBCS e Unicode do seu software

Caso contrário, você vai escorregar e usar char* comuns char* em muitos lugares.

Que você não use escapes de barra invertida não-ASCII em literais _T (“…”)

A menos que sua codificação “ANSI” seja ISO-8859-1, os literais char* e wchar_t* resultantes não representarão os mesmos caracteres.

Que seqüências de caracteres UTF-16 são usadas apenas como seqüências de caracteres “ANSI”

Eles não são. O Unicode introduz vários conceitos que não existem na maioria das codificações de caracteres legados. Substitutos Combinando personagens. Normalização. Regras de invólucro condicionais e sensíveis ao idioma.

E talvez o mais importante, o fato de que o UTF-16 raramente é salvo em disco ou enviado pela Internet: o UTF-8 tende a ser preferido para representação externa.

Que seu aplicativo não usa a Internet

(Agora, isso pode ser uma suposição válida para o seu software, mas …)

A web é executada em UTF-8 e uma infinidade de codificações mais raras . O conceito de TCHAR reconhece apenas dois: “ANSI” (que não pode ser UTF-8 ) e “Unicode” (UTF-16). Pode ser útil para tornar suas chamadas à API do Windows compatíveis com Unicode, mas é inútil para tornar seus aplicativos da Web e de email compatíveis com Unicode.

Que você não use bibliotecas não-Microsoft

Ninguém mais usa o TCHAR . O Poco usa std::string e UTF-8. O SQLite tem as versões UTF-8 e UTF-16 de sua API, mas não o TCHAR . TCHAR não está nem na biblioteca padrão, então não std::tcout menos que você queira definir você mesmo.

O que eu recomendo em vez de TCHAR

Esqueça que existem codificações “ANSI”, exceto quando você precisa ler um arquivo que não é válido UTF-8. Esqueça o TCHAR também. Sempre chame a versão “W” das funções da API do Windows. #define _UNICODE apenas para garantir que você não chame acidentalmente uma function “A”.

Sempre use codificações UTF para strings: UTF-8 para cadeias de caracteres e UTF-16 (no Windows) ou UTF-32 (em sistemas Unix-like) para cadeias de caracteres wchar_t . typedef tipos de caracteres UTF16 e UTF32 para evitar diferenças de plataforma.

Se você está se perguntando se ainda está em prática, então sim – ainda é usado um pouco. Ninguém vai olhar seu código engraçado se ele usar TCHAR e _T (“”). O projeto em que estou trabalhando agora está convertendo de ANSI para unicode – e estamos indo para a rota portátil (TCHAR).

Contudo…

Meu voto seria esquecer todas as macros portáveis ​​ANSI / UNICODE (TCHAR, _T (“”), e todas as chamadas _tXXXXXX, etc …) e apenas assumir o unicode em todos os lugares. Eu realmente não vejo o ponto de ser portátil se você nunca precisará de uma versão ANSI. Eu usaria todas as funções e tipos de caracteres largos diretamente. Preprenda todos os literais de string com um L.

O artigo Introdução ao Windows de programação no MSDN diz

Novos aplicativos devem sempre chamar as versões Unicode (da API).

As macros TEXT e TCHAR são menos úteis hoje em dia, porque todos os aplicativos devem usar o Unicode.

Eu iria ficar com wchar_t e L"" .

Eu gostaria de sugerir uma abordagem diferente (nenhuma das duas).

Para resumir, use char * e std :: string, assumindo a codificação UTF-8 e faça as conversões para UTF-16 somente ao agrupar as funções da API.

Mais informações e justificativas para essa abordagem em programas do Windows podem ser encontradas em http://www.utf8everywhere.org .

TCHAR / WCHAR pode ser suficiente para alguns projetos legados. Mas para novas aplicações, eu diria NÃO .

Todas essas coisas TCHAR / WCHAR estão lá por razões históricas. TCHAR fornece uma maneira aparentemente simples (disfarce) para alternar entre codificação de texto ANSI (MBCS) e codificação de texto Unicode (UTF-16). No passado, as pessoas não entendiam o número de caracteres de todas as línguas do mundo. Eles assumiram que 2 bytes foram suficientes para representar todos os caracteres e, portanto, ter um esquema de codificação de caracteres de comprimento fixo usando o WCHAR . No entanto, isso não é mais verdade após o lançamento do Unicode 2.0 em 1996 .

Isso quer dizer: Não importa qual você use em CHAR / WCHAR / TCHAR , a parte de processamento de texto em seu programa deve ser capaz de manipular caracteres de comprimento variável para internacionalização.

Então você realmente precisa fazer mais do que escolher um de CHAR / WCHAR / TCHAR para programar no Windows:

  1. Se seu aplicativo é pequeno e não envolve processamento de texto (ou seja, apenas passando a string de texto como argumentos), então fique com WCHAR . Já que é mais fácil trabalhar com WinAPI com suporte a Unicode.
  2. Caso contrário, sugiro usar o UTF-8 como codificação interna e armazenar textos em cadeias de caracteres ou std :: string. E convertê-los em UTF-16 ao chamar WinAPI. O UTF-8 é agora a codificação dominante e há muitas bibliotecas e ferramentas úteis para processar strings UTF-8.

Confira este site maravilhoso para uma leitura mais aprofundada: http://utf8everywhere.org/

Sim absolutamente; pelo menos para a macro _T. Eu não tenho tanta certeza sobre as coisas de caráter amplo, no entanto.

O motivo é suportar melhor o WinCE ou outras plataformas Windows não padrão. Se você tem 100% de certeza de que seu código permanecerá no NT, provavelmente poderá usar apenas declarações regulares de string C. No entanto, é melhor ter uma abordagem mais flexível, pois é muito mais fácil definir essa macro em uma plataforma que não seja o Windows, em comparação com milhares de linhas de código e adicioná-las em todos os lugares, caso precise portar alguma biblioteca para o Windows Mobile.

IMHO, se há TCHARs em seu código, você está trabalhando no nível errado de abstração.

Use qualquer tipo de string que seja mais conveniente para você quando estiver lidando com processamento de texto – isso provavelmente será algo que suporte o unicode, mas isso é com você. Faça a conversão nos limites da API do SO, conforme necessário.

Ao lidar com caminhos de arquivos, crie seu próprio tipo personalizado em vez de usar strings. Isso permitirá que você separadores de caminho independente do sistema operacional, lhe dará uma interface mais fácil de codificar do que concatenação de seqüência manual e divisão, e será muito mais fácil de se adaptar a diferentes sistemas operacionais (ansi, ucs-2, utf-8, qualquer) .

As únicas razões que vejo para usar qualquer coisa que não seja o WCHAR explícito são portabilidade e eficiência.

Se você quiser tornar seu executável final o menor possível, use char.

Se você não se importa com o uso da RAM e deseja que a internacionalização seja tão fácil quanto uma simples tradução, use o WCHAR.

Se você quiser tornar seu código flexível, use o TCHAR.

Se você planeja usar apenas os caracteres latinos, é melhor usar as cadeias ASCII / MBCS para que o usuário não precise de muita RAM.

Para pessoas que são “i18n desde o início”, salve-se do espaço do código-fonte e simplesmente use todas as funções do Unicode.

Apenas adicionando a uma pergunta antiga:

NÃO

Vá iniciar um novo projeto CLR C ++ no VS2010. A própria Microsoft usa L"Hello World" , disse Nuff.