TCHAR est-il toujours d'actualité?

Question

Je suis nouveau dans la programmation Windows et après avoir lu le livre Petzold, je me demande:

existe-t-il toujours une bonne pratique d'utiliser le type TCHAR et la fonction _T () pour déclarer des chaînes ou si je devrais utiliser simplement le wchar_t et L chaînes "" " dans le nouveau code?

Je ne ciblerai que Windows 2000 et les versions ultérieures et mon code sera i18n dès le départ. .

Answer 1

J'utiliserais encore la syntaxe TCHAR si je réalisais un nouveau projet aujourd'hui. Il n'y a pas beaucoup de différence pratique entre son utilisation et la syntaxe WCHAR, et je préfère un code explicite quant au type de caractère. Comme la plupart des fonctions API et des objets utilitaires prennent / utilisent des types TCHAR (par exemple: CString), il est logique de les utiliser. De plus, cela vous donne de la flexibilité si vous décidez d’utiliser le code dans une application ASCII à un moment donné ou si Windows évolue un jour vers Unicode32, etc.

Si vous décidez d'utiliser la route WCHAR, je serais explicite à ce sujet. Autrement dit, utilisez CStringW au lieu de CString et transformez des macros lors de la conversion en TCHAR (par exemple: CW2CT).

C'est mon avis, de toute façon.

Answer 2

La réponse courte: NON .

Comme tous les autres déjà écrit, beaucoup de programmeurs utilisent encore TCHAR et les fonctions correspondantes. À mon humble avis, le concept dans son ensemble était une mauvaise idée . Le traitement de la chaîne UTF-16 est très différent de la simple chaîne ASCII / MBCS. En traitement. Si vous utilisez les mêmes algorithmes / fonctions avec les deux (c'est sur cela que repose l'idée de TCHAR!), Vous obtenez de très mauvaises performances sur la version UTF-16 si vous faites un peu plus que la simple concaténation de chaînes (comme analyse etc.). Les Surrogates en sont la principale raison.

À la seule exception lorsque vous vraiment devez compiler votre application pour un système qui ne prend pas en charge Unicode, je ne vois aucune raison d'utiliser ce bagage du passé dans une nouvelle application.

Answer 3

Je suis d'accord avec Sascha. La prémisse sous-jacente de TCHAR / _T () / etc. est que vous pouvez écrire une application basée sur "ANSI" puis lui donner par magie le support Unicode en définissant une macro . Mais ceci est basé sur plusieurs mauvaises hypothèses:

Vous avez activement créé les versions MBCS et Unicode de votre logiciel

Sinon, vous échapperez à l'utilisation de chaînes char * ordinaires à de nombreux endroits.

Ne pas utiliser d'espaces de barre oblique inversée non ASCII dans les littéraux _T ("...")

Sauf si votre " ANSI " Le codage est ISO-8859-1, les littéraux char * et ainsi que wchar_t * obtenus ne représentent pas les mêmes caractères.

Les chaînes UTF-16 sont utilisées exactement comme "ANSI". chaînes

Ils ne le sont pas. Unicode introduit plusieurs concepts qui n'existent pas dans la plupart des encodages de caractères hérités. Substituts. Combinaison de personnages. Normalisation. Règles de casse conditionnelles et sensibles à la langue.

Et peut-être plus important encore, le fait que le format UTF-16 soit rarement sauvegardé sur disque ou envoyé sur Internet: le format UTF-8 est plutôt préféré pour la représentation externe.

Que votre application n'utilise pas Internet

(Maintenant, cela peut être une hypothèse valable pour votre logiciel , mais ...)

Le Web fonctionne sous UTF-8 et une pléthore d’encodages plus rares . Le concept TCHAR n'en reconnaît que deux: " ANSI " (qui ne peut pas être UTF-8 ) et "Unicode". (UTF-16). Cela peut être utile pour rendre vos appels API Windows compatibles avec Unicode, mais inutile pour rendre vos applications Web et de messagerie compatibles Unicode.

N'utilisez aucune bibliothèque autre que Microsoft

Personne d'autre n'utilise TCHAR . Poco utilise std :: string et UTF-8. SQLite possède les versions UTF-8 et UTF-16 de son API, mais pas de TCHAR . . TCHAR n'est même pas dans la bibliothèque standard, donc pas std :: tcout à moins que vous ne vouliez le définir vous-même.

Ce que je recommande au lieu de TCHAR

Oubliez cela " ANSI " Il existe des codages, sauf lorsque vous devez lire un fichier non valide UTF-8. Oubliez aussi TCHAR . Appelez toujours le " W " version des fonctions de l'API Windows. #define _UNICODE uniquement pour vous assurer que vous n'appelez pas accidentellement un "A"; fonction.

Toujours utiliser les codages UTF pour les chaînes: UTF-8 pour les chaînes char et UTF-16 (sous Windows) ou UTF-32 (sur les systèmes de type Unix) pour wchar_t des chaînes. typedef UTF16 et UTF32 pour éviter les différences de plate-forme.

Answer 4

Si vous vous demandez si cela se pratique encore, alors oui, il est encore assez utilisé. Personne ne regardera votre code de façon amusante s’il utilise TCHAR et _T (""). Le projet sur lequel je travaille maintenant consiste à convertir d'ANSI en unicode - et nous empruntons la route portable (TCHAR).

Cependant ...

Mon vote serait d'oublier toutes les macros portables ANSI / UNICODE (TCHAR, _T (")" et tous les appels _tXXXXXX, etc.) et d'assumer unicode partout. Je ne vois vraiment pas l'intérêt d'être portable si vous n'avez jamais besoin d'une version ANSI. J'utiliserais directement toutes les fonctions et types de caractères larges. Préposez tous les littéraux de chaîne avec un L.

Answer 5

L'article Introduction à la programmation Windows sur MSDN dit

  

Les nouvelles applications doivent toujours appeler les versions Unicode (de l'API).

     

Les macros TEXT et TCHAR sont moins utiles aujourd'hui, car toutes les applications doivent utiliser Unicode.

Je voudrais m'en tenir à wchar_t et à L "" .

Answer 6

Je voudrais suggérer une approche différente (aucune des deux).

Pour résumer, utilisez char * et std :: string, en supposant le codage UTF-8, et effectuez les conversions au format UTF-16 uniquement lors du wrapping des fonctions de l'API.

Vous trouverez plus d'informations et une justification sur cette approche dans les programmes Windows dans http://www.utf8everywhere.org .

Answer 7

TCHAR / WCHAR pourrait suffire pour certains projets hérités. Mais pour les nouvelles applications, je dirais NON .

Tous ces éléments TCHAR / WCHAR existent pour des raisons historiques. TCHAR fournit un moyen (déguisement) apparemment simple de basculer entre le codage de texte ANSI (MBCS) et le codage de texte Unicode (UTF-16). Dans le passé, les gens ne comprenaient pas le nombre de caractères de toutes les langues du monde. Ils ont supposé que 2 octets étaient suffisants pour représenter tous les caractères et donc un schéma de codage de caractères de longueur fixe utilisant WCHAR . Toutefois, ce n'est plus le cas après la sortie de l'Unicode 2.0 en 1996 .

C'est-à-dire: Peu importe ce que vous utilisez dans CHAR / WCHAR / TCHAR , la partie de traitement de texte de votre programme doit pouvoir gérer longueur variable caractères pour l'internationalisation.

Vous devez donc faire plus que choisir un élément parmi CHAR / WCHAR / TCHAR pour la programmation sous Windows:

1. Si votre application est petite et n'implique pas de traitement de texte (c'est-à-dire qu'il suffit de passer la chaîne de texte sous forme d'arguments), restez-en à WCHAR . Comme il est plus facile de travailler avec WinAPI avec le support Unicode.
2. Sinon, je suggérerais d'utiliser UTF-8 comme encodage interne et de stocker les textes dans des chaînes de caractères ou dans std :: string. Et convertissez-les en UTF-16 lorsque vous appelez WinAPI. UTF-8 est désormais l'encodage dominant. Il existe de nombreuses bibliothèques et outils pratiques pour traiter les chaînes UTF-8.

Consultez ce site Web merveilleux pour une lecture plus approfondie: http://utf8everywhere.org/

Answer 8

Oui, absolument. au moins pour la macro _T. Je ne suis cependant pas si sûr de ce qui concerne les caractères larges.

La raison en est de mieux prendre en charge WinCE ou d’autres plates-formes Windows non standard. Si vous êtes sûr à 100% que votre code restera sur NT, vous pouvez probablement simplement utiliser des déclarations C-string classiques. Cependant, il est préférable de tendre vers une approche plus flexible, car il est beaucoup plus facile de # définir cette macro sur une plateforme autre que Windows en comparant des milliers de lignes de code et en l'ajoutant partout au cas où vous auriez besoin de porter une bibliothèque. sur Windows Mobile.

Answer 9

IMHO, s'il y a des codes TCHAR dans votre code, vous travaillez au mauvais niveau d'abstraction.

Utilisez le type de chaîne qui vous convient le mieux lors du traitement de texte - cela devrait être un support de l'unicode, mais cela dépend de vous. Effectuez la conversion si nécessaire aux limites des API OS.

Lorsque vous traitez avec des chemins de fichiers, créez votre propre type personnalisé au lieu d'utiliser des chaînes. Cela vous permettra d'utiliser des séparateurs de chemin indépendants du système d'exploitation, une interface plus facile à coder que la concaténation et le fractionnement manuels de chaînes, et sera beaucoup plus facile à adapter à différents systèmes d'exploitation (ansi, ucs-2, utf-8, peu importe). .

Answer 10

Les seules raisons pour lesquelles je vois utiliser autre chose que la WCHAR explicite sont la portabilité et l'efficacité.

Si vous voulez rendre votre exécutable final aussi petit que possible, utilisez char.

Si vous ne vous souciez pas de l'utilisation de la mémoire RAM et que vous voulez que l'internationalisation soit aussi simple que la traduction, utilisez WCHAR.

Si vous souhaitez assouplir votre code, utilisez TCHAR.

Si vous envisagez uniquement d'utiliser les caractères latins, vous pouvez également utiliser les chaînes ASCII / MBCS afin que votre utilisateur n'ait pas besoin de plus de RAM.

Pour les personnes qui sont "libérées dès le démarrage", économisez vous-même l'espace du code source et utilisez simplement toutes les fonctions Unicode.

Answer 11

Il suffit d'ajouter à une vieille question:

NON

Commencez un nouveau projet CLR C ++ dans VS2010. Microsoft utilise lui-même L "Hello World" , a déclaré Nuff.