É TCHAR ainda é relevante?

Question

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

ainda é boa prática para usar o tipo de TCHAR ea função _T() declarar cordas ou se eu deveria usar apenas as cordas wchar_t e L"" no novo código?

I terá como alvo apenas o Windows 2000 e para cima e meu código será i18n do arranque .

Answer 1

Eu ainda usaria a sintaxe TCHAR se eu estava fazendo um novo projeto hoje. Não há muita diferença prática entre usá-lo e a sintaxe WCHAR, e eu prefiro código que está explícito no que o tipo de personagem é. Como a maioria das funções da API e objetos auxiliares tomar / uso tipos TCHAR (por exemplo .: CString), ele só faz sentido usá-lo. Além disso, ele dá-lhe flexibilidade, se você decidir usar o código em um aplicativo ASCII em algum momento, ou se o Windows nunca evolui para Unicode32, etc.

Se você decidir ir a rota WCHAR, gostaria de ser explícito sobre isso. Ou seja, usar CStringW vez de CString, e lançando macros ao converter para TCHAR. (Por exemplo: CW2CT)

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

Answer 2

A resposta curta:. NÃO

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

Com a única exceção quando você realmente precisa compilar o aplicativo para um sistema que não suporta Unicode não vejo razão para usar esta bagagem do passado em uma nova aplicação.

Answer 3

Eu tenho que concordar com Sascha. A premissa subjacente da 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ê ativamente construir ambos MBCS e versões Unicode do seu software

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

Que você não usar escapes barra invertida não-ASCII em _T ( "...") literais

A menos que sua codificação "ANSI" passa a ser ISO-8859-1, os char* e wchar_t* resultantes literais não representam os mesmos personagens.

que o UTF-16 cordas são usados ??como cordas "ANSI"

Não são. Unicode apresenta vários conceitos que não existem na maioria das codificações de caracteres legado. Surrogates. Combinando caracteres. Normalização. Condicional e regras de revestimento sensível à linguagem.

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

Que o seu aplicativo não usar a Internet

(Agora, isto pode ser uma suposição válida para o software, mas ...)

A Web é executado em UTF-8 e uma infinidade de raras codificações . O conceito TCHAR reconhece apenas dois: "ANSI" (que não pode ser UTF-8 ) e "Unicode" (UTF-16). Pode ser útil para fazer a sua API do Windows chama Unicode-aware, mas está condenado inútil para fazer sua web e e-mail aplicativos Unicode-aware.

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

Ninguém mais usa TCHAR. Poço usos std::string e UTF-8. SQLite tem UTF-8 e UTF-16 versões de sua API, mas não TCHAR. TCHAR não é nem mesmo na biblioteca padrão, por isso não std::tcout a menos que você deseja definir-lo sozinho.

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 TCHAR também. Sempre chamar a versão "W" de funções da API do Windows. #define _UNICODE apenas para se certificar que você não acidentalmente chamar uma função "A".

Sempre codificações usar UTF para cordas: UTF-8 para cordas char e UTF-16 (no Windows) ou UTF-32 (em Unix-like sistemas) para cordas wchar_t. typedef UTF16 e caráter UTF32 tipos de diferenças de plataforma evitar.

Answer 4

Se você está querendo saber se ele ainda está em prática, então sim - ele ainda é usado um pouco. Ninguém vai olhar para o seu código engraçado se usa TCHAR e _T ( ""). O projeto que estou trabalhando agora é a conversão de ANSI para unicode -. E nós estamos indo a rota portátil (TCHAR)

No entanto ...

Meu voto seria esquecer todas as macros ANSI / Unicode portáteis (TCHAR, _T ( ""), e todas as chamadas _tXXXXXX, etc ...) e apenas supor unicode em todos os lugares. Eu realmente não vejo o ponto de ser portátil se você nunca vai precisar de uma versão ANSI. Gostaria de usar todas as funções de caracteres largos e tipos diretamente. Preprend todas as strings literais com um L.

Answer 5

O artigo Programação Introdução ao Windows em MSDN diz

Novas aplicações deve sempre chamar as versões Unicode (da API).

O texto e TCHAR macros são menos úteis hoje, porque todas as aplicações devem utilizar Unicode.

eu iria ficar para wchar_t e L"".

Answer 6

Gostaria de sugerir uma abordagem diferente (nenhum dos dois).

Para resumir, utilização e char * std :: cadeia, assumindo codificação UTF-8, e fazer as conversões para UTF-16 apenas quando funções envolvimento API.

Mais informações e justificação para esta abordagem em programas do Windows podem ser encontradas no http://www.utf8everywhere.org .

Answer 7

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

Todos estes coisas TCHAR / WCHAR estão lá por causa de razões históricas. TCHAR fornece uma maneira conveniente puro (disfarce) para alternar entre a codificação ANSI texto (MBCS) e codificação de texto Unicode (UTF-16). No passado, as pessoas não têm uma compreensão do número de caracteres de todas as línguas do mundo. Eles assumido 2 bytes foram suficientes para representar todos os caracteres e tendo assim um esquema de codificação de caracteres de comprimento fixo usando WCHAR. No entanto, isso não é mais verdade após o lançamento do Unicode 2.0 em 1996 .

Quer dizer: Não importa o que você usa no CHAR / WCHAR / TCHAR, a parte de processamento de texto em seu programa deve ser capaz de lidar comprimento variável caracteres para a internacionalização.

Assim que você realmente precisa fazer mais do que escolher um de CHAR / WCHAR / TCHAR para a programação no Windows:

1. Se o seu aplicativo é pequeno e não envolve o processamento de texto (ou seja, só de passagem em torno da cadeia de texto como argumentos), então ficar com WCHAR. Uma vez que é mais fácil desta maneira de trabalhar com WinAPI com suporte a Unicode.
2. Caso contrário, eu sugiro usar UTF-8 como codificação e armazenar textos internos em strings CHAR ou std :: string. E convertê-los para UTF-16 ao chamar WinAPI. UTF-8 agora é a codificação dominante e há muitas bibliotecas úteis e ferramentas para processo UTF-8 cordas.

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

Answer 8

Sim, absolutamente; pelo menos para a macro _T. Eu não tenho tanta certeza sobre o material de caracteres largos, embora.

A razão de ser é a melhor suporte WinCE ou outras plataformas não-padrão do Windows. Se você é 100% certo que seu código permanecerá no NT, então provavelmente você pode simplesmente usar declarações regulares C-corda. No entanto, é melhor a tender para a abordagem mais flexível, pois é muito mais fácil de #define que longe macro em uma plataforma não-Windows em comparação com indo através de milhares de linhas de código e adicioná-lo em todos os lugares em caso de necessidade de porta alguma biblioteca para o Windows mobile.

Answer 9

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

Use qualquer que seja tipo de cadeia é mais conveniente para você quando se trata de processamento de texto - este será espero que algo de suporte unicode, mas isso é até você. Fazer a conversão em limites de API do sistema operacional, se necessário.

Ao lidar com caminhos de arquivo, chicote de seu próprio tipo personalizado em vez de usar cordas. Isso permitirá que você separadores de caminho OS-independentes, lhe dará uma interface mais fácil de código contra a concatenação manual e divisão, e será muito mais fácil de se adaptar a diferentes sistemas operacionais (ANSI, UCS-2, utf-8, qualquer que seja) .

Answer 10

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

Se você quiser fazer o seu executável final tão pequena quanto possível de char uso.

Se você não se preocupam com o uso de RAM e quer internacionalização para ser tão fácil como simples tradução, uso WCHAR.

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

Se você está pensando apenas em utilizar os caracteres latinos, assim como você pode usar as seqüências ASCII / MBCS para que o usuário não precisa de tanta RAM.

Para as pessoas que são "i18n do arranque", salve-se o espaço de código fonte e simplesmente usar todas as funções Unicode.

Answer 11

Basta adicionar a uma velha questão:

NO

Vai iniciar um novo projeto CLR C ++ no VS2010. Microsoft-se usar L"Hello World" ', nuff disse.