Est TCHAR-elle toujours pertinente?

Je suis nouveau à la programmation sous Windows et après la lecture de la Petzold livre, je me demande:

est-il toujours de bonne pratique d'utiliser le TCHAR type et la _T() fonction de déclarer des chaînes ou si je dois juste utiliser le wchar_t et L"" chaînes dans le nouveau code?

Je vais cibler uniquement Windows 2000 et mon code sera i18n de la start-up.

InformationsquelleAutor Fábio | 2008-10-24
  1. 15

    J'ai toujours utiliser le TCHAR syntaxe si je faisais un nouveau projet aujourd'hui. Il n'y a pas beaucoup de différence pratique entre l'aide et de l'WCHAR syntaxe, et je préfère de code qui est explicite dans ce que le type de caractère est. Puisque la plupart des fonctions de l'API et les objets d'aide à la prise/utilisation TCHAR types (par exemple: CString), il est logique de l'utiliser. De Plus il vous donne de la souplesse si vous décidez d'utiliser le code dans un fichier ASCII application à un certain point, ou si Windows jamais évolue à Unicode32, etc.

    Si vous décidez d'aller de l'WCHAR route, je serais explicite à ce sujet. Qui est, l'utilisation CStringW au lieu de CString, et le moulage des macros lors de la conversion de TCHAR (par exemple: CW2CT).

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

    • En effet, c'est ce que continue de fonctionner lorsque le codage des caractères est finalement changé "nouveau".
    • Vous préférez le code qui est explicite dans ce que le type de caractère est, et donc utiliser un type qui est parfois présent et parfois ça? Très convaincant.
    • -1 de l'incohérence noté par @Deduplicator, et pour le négatif profit des conseils pour utiliser une macro qui peut être n'importe quoi (et ne sera généralement pas testé plus d'une valeur spécifique).
    InformationsquelleAutor Nick
  2. 88

    La réponse courte: PAS.

    Comme tous les autres ont déjà écrit, beaucoup de programmeurs utilisent encore TCHARs et les fonctions correspondantes. À mon humble avis le concept était une mauvaise idée. UTF-16 chaîne de traitement est très différent que de simples ASCII/MBCS chaîne de traitement. Si vous utilisez les mêmes algorithmes/fonctions avec deux d'entre eux (c'est ce que le TCHAR idée est de partir!), vous obtenez une très mauvaise performance sur l'UTF-16 version si vous faites un peu plus que de la simple concaténation de chaîne (comme l'analyse etc.). La raison principale sont Les mères porteuses.

    À 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.

    • Fait amusant: UTF-16 n'était pas toujours là, sur la plate-forme NT. De substitution des points de code ont été introduites avec Unicode 2.0, en 1996, qui était de la même année, NT 4 est sorti. Jusqu'à ce que, autant que je me souvienne, (y compris) de Windows 2000, toutes les versions NT utilisé UCS-2, effectivement un sous-ensemble de l'UTF-16 qui a pris le chaque personnage pour être présentable avec un seul point de code (c'est à dire pas des substituts).
    • btw, alors que je suis d'accord que TCHAR ne doit pas être utilisée plus, je suis en désaccord que c'était une mauvaise idée. Je pense aussi que si vous choisissez d'être explicite au lieu d'utiliser TCHAR vous devez être explicite partout. I. e. ne pas utiliser des fonctions avec TCHAR/_TCHAR (comme _tmain) dans leur déclaration soit. Il suffit de mettre: être cohérent. +1, toujours.
    • C' était une bonne idée en arrière quand il a été introduit, mais il devrait être hors de propos dans le nouveau code.
    • Vous prétendez à tort, que TCHARs ont été initialement introduit pour: Pour faciliter le développement de code pour Win 9x et Windows NT versions de Windows. À l'époque, Windows NT UTF-16 de la mise en œuvre a été UCS-2, et les algorithmes de traitement de chaîne/de manipulation étaient identiques. Il n'y avait pas de substituts. Et même avec des mères porteuses, des algorithmes pour DBCS (la seule prise en charge de codage MBCS pour Windows) et UTF-16 sont les mêmes: Dans les deux de codage, un point de code se compose d'une ou de deux unités de code.
    • Supposons que je veux utiliser FormatMessage() pour convertir une valeur de WSAGetLastError() pour quelque chose de imprimable. La documentation pour WSAGetLastError() dit qu'il prend LPTSTR comme le pointeur vers la mémoire tampon. Je n'ai pas vraiment beaucoup de choix, mais d'utiliser TCHAR, non?
    • ne prend aucun argument, donc je suppose que vous faites allusion à l' FormatMessage. Comme la documentation souligne, il y a une Unicode à l'exportation, FormatMessageW, qui prend un LPWSTR. Pas besoin d'utiliser le générique de texte mappages. Cela est vrai pour presque tous les appels d'API de Windows qui prennent des arguments de chaîne.

    InformationsquelleAutor Sascha
  3. 77

    Je suis d'accord avec Sascha. Le principe sous-jacent de TCHAR /_T() /etc. est que vous pouvez écrire un "ANSI"-fondé sur l'application et puis comme par magie lui donner le support de l'Unicode par la définition d'une macro. Mais ceci est basé sur plusieurs hypothèses erronées:

    Que vous activement à construire à la fois MBCS et Unicode versions de vos logiciels

    Sinon, vous sera glisser vers le haut et l'utilisation ordinaire char* chaînes dans de nombreux endroits.

    Que vous n'utilisez pas de caractères non ASCII des antislashes dans _T("...") littéraux

    À moins que votre "ANSI" encoding arrive à être en ISO-8859-1, le char* et wchar_t* littéraux de ne pas présenter les mêmes caractères.

    Que UTF-16 chaînes sont utilisées comme "ANSI" les chaînes

    Ils ne le sont pas. Unicode introduit plusieurs concepts qui n'existent pas dans la plupart de l'héritage des codages de caractères. Les mères porteuses. Les combinaisons de caractères. La normalisation. Conditionnelle et de la langue-sensible règles de casse.

    Et peut-être plus important encore, le fait que l'UTF-16 est rarement enregistrées sur le disque ou de les envoyer sur Internet: UTF-8 tend à être privilégiée pour la représentation externe.

    Que votre application n'utilise pas l'Internet

    (C'est peut-être une hypothèse valable pour votre logiciel, mais...)

    Le web s'exécute sur l'UTF-8 et une pléthore de plus rares encodages. Le TCHAR concept ne reconnaît que deux: "ANSI" (qui vous ne pouvez pas être en UTF-8) et "Unicode" (UTF-16). Il peut être utile pour faire vos appels d'API de Windows Unicode, mais c'est bougrement inutile pour faire de votre site web et adresse e-mail apps Unicode.

    Que vous n'utilisez aucune non-Microsoft bibliothèques

    Personne d'autre ne l'utilise TCHAR. Poco utilise std::string et UTF-8. SQLite a UTF-8 et UTF-16 versions de son API, mais pas de TCHAR. TCHAR n'est même pas dans la bibliothèque standard, donc pas de std::tcout sauf si vous voulez définir vous-même.

    Ce que je recommande, au lieu de TCHAR

    Oublier que "ANSI" codages existent pas, sauf quand vous avez besoin de lire un fichier qui n'est pas UTF-8 valide. Oublier TCHAR trop. Toujours appeler le "W" de la version de fonctions de l'API Windows. #define _UNICODE juste pour vous assurer de ne pas accidentellement de l'appel d'une fonction "A".

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

    • 2012 appel: il y a encore des demandes pour être maintenue sans #define _UNICODE, même maintenant. Fin de transmission 🙂
    • la question était de savoir nouvelles code. Lorsque vous entretenir de l'ancien code, vous avez évidemment à travailler avec l'environnement que le code est écrit pour. Si vous êtes le maintien d'une application COBOL, alors il n'a pas d'importance si le COBOL est un langage de qualité ou pas, vous êtes coincé avec elle. Et si vous êtes le maintien d'une demande qui s'appuie sur TCHAR alors il n'a pas d'importance si c'était une bonne décision ou pas, vous êtes coincé avec elle.
    • En effet, TCHAR n'est pas utile sauf en COBOL)
    • _UNICODE contrôle la façon dont le générique de texte mappages sont résolus dans le CRT. Si vous ne souhaitez pas appeler la version ANSI de l'API de Windows, vous devez définir UNICODE.
    InformationsquelleAutor dan04
  4. 18

    Si vous vous demandez si elle est encore dans la pratique, alors oui - il est toujours utilisé un peu. Personne ne regarde votre code drôle si elle utilise TCHAR et _T(""). Le projet sur lequel je travaille actuellement est la conversion de l'ANSI en unicode - et nous allons le portable (TCHAR) l'itinéraire.

    Cependant...

    Mon vote serait oublier toutes les normes ANSI/UNICODE portable macros (TCHAR, _T(""), et tous les _tXXXXXX appels, etc...) et il suffit de supposer unicode partout. Je ne vois vraiment pas le point d'être portable si vous n'avez pas besoin d'une version ANSI. Je voudrais utiliser tous les caractères larges de fonctions et de types directement. Preprend tous les littéraux de chaîne avec un L.

    • Vous pourriez écrire un peu de code que vous souhaitez utiliser à tout autre endroit où vous avez besoin d'une version ANSI, ou (comme Nick l'a dit) de Windows peut se déplacer à DCHAR ou que ce soit, donc je pense toujours que c'est une très bonne idée d'aller avec TCHAR au lieu de WCHAR.
    • très bon point.
    • sérieusement...?
    • Je doute que Windows va toujours passer à l'UTF-32.
    • -1 pour l'UTF-16 de la recommandation. Non seulement cela crée non portable (windows-centric) du code, ce qui est inacceptable pour les bibliothèques - même si peut-être utilisé pour le cas le plus simple comme le code de l'INTERFACE utilisateur - elle n'est pas efficace, même sur Windows lui-même. utf8everywhere.org
    InformationsquelleAutor Aardvark
  5. 11

    La Introduction à la Programmation sous Windows l'article sur MSDN dit

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

    La TEXTE et TCHAR macros sont de moins en moins utile aujourd'hui, car toutes les applications devraient utiliser l'Unicode.

    Je m'en tiendrais à wchar_t et L"".

    • Steven, vous citez un texte écrit par quelqu'un qui ne comprend pas le sens du mot "Unicode". Il est l'un de ces malheureux documents à partir du moment de l'UCS-2 de la confusion.
    • Le document a été écrit pour un système, où Unicode et UTF-16LE sont souvent utilisés de façon interchangeable. Bien que techniquement inexact, il est néanmoins sans ambiguïté. C'est d'ailleurs explicitement indiqué dans l'introduction du même texte: "Windows représente des caractères Unicode à l'aide de l'encodage UTF-16 [...]".
    InformationsquelleAutor Steven
  6. 10

    Je voudrais proposer une approche différente (aucun des deux).

    Pour résumer, utiliser des char* et std::string, en supposant que l'encodage UTF-8, et de faire les conversions à l'UTF-16 seulement en enveloppant des fonctions de l'API.

    Plus d'informations et la justification de cette approche dans les programmes Windows peut être trouvé dans http://www.utf8everywhere.org.

    • Essentiellement ce dan04 dit.
    • mais plus court....
    • lors de la mise en œuvre de votre suggestion dans un VC++ de l'application, définir la VC++ personnage réglé sur "Aucun" ou " multi-octets (MBCS)'? La raison que je demande, c'est que je viens d'installer Boost::Locale et le jeu de caractères par défaut a été MBCS. FWIW, mon pur ASCII application a la valeur 'None' et j'ai maintenant le mettre à " MBCS (depuis que je vais utiliser Boost::Locale) et il fonctionne très bien. Veuillez informer.
    • Comme utf8everywhere recommande, je voudrais le mettre à "l'Utilisation de caractères Unicode set". Ces annonces une sécurité supplémentaire, mais il n'est pas nécessaire. Boost::paramètres régionaux de l'auteur est un gars très intelligent, je suis sûr qu'il a fait la bonne chose.
    • Le UTF-8 Partout mantra ne deviendra pas la bonne solution, juste parce qu'il est répété plus souvent. UTF-8 est sans aucun doute une séduisante codant pour la sérialisation (par exemple, des fichiers ou des sockets réseau), mais sous Windows il est souvent plus appropriée, pour stocker des données de caractères en utilisant le natif de l'encodage UTF-16 en interne, et de les convertir à la limite d'application. Une raison en est, que l'UTF-16 est le seul encodage, qui peuvent être immédiatement convertis en tout autre codage pris en charge. Ce n'est pas le cas avec l'encodage UTF-8.
    • "..UTF-16 est le seul encodage, qui peuvent être immédiatement convertis en tout autre codage pris en charge." que voulez-vous dire? Quel est le problème pour convertir l'encodage UTF-8 pour autre chose?
    • le problème pour convertir l'encodage UTF-8 pour quelque chose d'autre?" - ce n'est pas ce que j'ai dit. Vous pouvez immédiatement convertir en UTF-8, UTF-16, appelant MultiByteToWideChar. Mais vous ne pouvez pas convertir en UTF-8 à autre chose, sans d'abord la conversion UTF-16.
    • Je ne comprends pas. À quoi que ce soit d'autre - comme quoi? E. g. UCS-4? Pourquoi pas? Semble très facile, tout algorithme numérique..

    InformationsquelleAutor Pavel Radzivilovsky
  7. 6

    TCHAR/WCHAR peut être suffisant pour certains anciens projets. Mais pour les nouvelles demandes, je dirais PAS.

    Tous ces TCHAR/WCHAR choses sont là à cause de raisons historiques. TCHAR fournit un convenable façon soignée (déguisement) pour basculer entre les normes ANSI encodage de texte (MBCS) et l'encodage Unicode (UTF-16). Dans le passé, les gens n'ont pas une compréhension de la nombre de caractères de toutes les langues dans le monde. Ils ont supposé que 2 octets ont été suffisantes pour représenter tous les caractères et de ce fait ayant un caractère de longueur fixe schéma de codage à l'aide de WCHAR. Cependant, ce n'est plus vrai après la sortie de l'Unicode 2.0 dans 1996.

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

    Si vous avez réellement besoin de faire plus que de choisir l'un de CHAR/WCHAR/TCHAR pour la programmation de Windows:

    1. Si votre application est petite et n'implique pas de traitement de texte (c'est à dire juste en passant autour de la chaîne de texte comme arguments), puis coller avec WCHAR. Car il est plus facile de cette façon de travailler avec WinAPI avec le support de l'Unicode.
    2. Sinon, je suggère l'utilisation de l'UTF-8 comme encodage interne et d'enregistrer les textes en char chaînes ou std::string. Et secrètes, à l'UTF-16 lors de l'appel de WinAPI. UTF-8 est maintenant le principal encodage et il y a beaucoup de pratique des bibliothèques et des outils pour traiter des chaînes UTF-8.

    Découvrez ce merveilleux site web pour une lecture plus détaillée:
    http://utf8everywhere.org/

    • "UTF-8 est maintenant le principal encodage" - Ce qui aurait mal tourné, en laissant de côté la deuxième partie de la citation ("pour le World Wide Web"). Pour les applications de bureau, le plus utilisé natif de l'encodage des caractères est probablement encore en UTF-16. Windows utilise, Mac OS X n', trop, et ainsi de le faire .NET et Java types de chaînes. Cela ne représente qu'une massif la quantité de code là-bas. Ne m'obtenez pas le mal, il n'y a rien de mal avec l'encodage UTF-8 pour la sérialisation. Mais le plus souvent (surtout sur Windows), vous trouverez que l'utilisation d'UTF-16 en interne est plus approprié.
    InformationsquelleAutor LeOpArD
  8. 4

    Oui, absolument, au moins pour le _T macro. Je ne suis pas si sûr sur le caractère des choses, cependant.

    La raison d'être est de mieux soutenir les WinCE ou non standard, les plates-formes Windows. Si vous êtes certain à 100% que votre code restera sur NT, alors vous pouvez probablement juste de l'utilisation régulière de C-string déclarations. Cependant, il est préférable de tendre vers une approche plus flexible, car il est beaucoup plus facile à #define macro sur une plate-forme non windows en comparaison à aller au moyen de milliers de lignes de code et l'ajout de partout dans le cas où vous avez besoin de le port certains de la bibliothèque de windows mobile.

    • WinCE utilise 16 bits wchar_t des chaînes de caractères comme Win32. Nous avons une grande base de code qui s'exécute sur WinCE et Win32 et nous n'utilisons jamais de TCHAR.
    InformationsquelleAutor Nik Reiman
  9. 2

    À mon humble avis, si il y a TCHARs dans votre code, vous travaillez au mauvais niveau d'abstraction.

    Utilisation quelle que soit type de chaîne est plus pratique pour vous lorsque vous traitez avec traitement de texte - ce sera, j'espère, quelque chose de la prise en charge unicode, mais c'est à vous de voir. Faire de la conversion à l'OS API limites que nécessaire.

    Lorsque vous traitez avec des chemins d'accès aux fichiers, concocter votre propre type, au lieu d'utiliser des chaînes de caractères. Cela vous permettra d'exploitation et des séparateurs de chemin, vous donnera une interface facile à code à l'encontre de manuel de concaténation de chaîne et de fractionnement, et sera beaucoup plus facile de s'adapter à différents Systèmes d'exploitation (ansi, ucs-2, utf-8, peu importe).

    • Unicode a au moins trois jeux de caractères (UTF-8, UTF-16, UTF-32) et une déconseillé d'encodage (UCS-2, un sous-ensemble de ce qui est maintenant en UTF-16). Laquelle pensez-vous allusion? J'aime le reste de l'suggestions si +1
    InformationsquelleAutor snemarch
  10. 2

    La seule raison que je vois à utiliser autre chose que de l'explicite WCHAR sont la mobilité et l'efficacité.

    Si vous voulez faire de votre exécutable final aussi petite que possible l'utilisation de char.

    Si vous n'avez pas de soins sur l'utilisation de la RAM et souhaitez internationalisation pour être aussi facile que de la simple traduction, l'utilisation WCHAR.

    Si vous voulez faire de votre code flexible, utilisez TCHAR.

    Si vous prévoyez sur l'utilisation des caractères latins, vous pourriez aussi bien utiliser l'ASCII/les chaînes MBCS de sorte que votre utilisateur n'a pas besoin d'autant de RAM.

    Pour les personnes qui sont "i18n de la start-up", vous sauver vous-même le code source de l'espace et de simplement utiliser toutes les fonctions Unicode.

    InformationsquelleAutor Trololol
  11. -1

    Juste en ajoutant à une vieille question:

    PAS

    Aller commencer une nouvelle CLR projet C++ dans VS2010. Microsoft utilisent eux-mêmes L"Hello World", 'nuff said.

    • +1 : c'est un argument 🙂
    • Le CLR est un environnement très différent que le code non managé. C'est pas un argument.
    • Même Microsoft fait des erreurs.
    • -1 La question est balisé C et C++. Les réponses peuvent toujours être supprimés par leurs auteurs respectifs. Ce serait un bon moment pour utiliser cette disposition.
    InformationsquelleAutor kizzx2