Je suis nouveau à la programmation Windows et après avoir lu le livre de Petzold, je me demande :
Il est toujours conseillé d’utiliser le type et le function pour déclarer les cordes ou si je dois juste utiliser le et chaînes dans le nouveau code ?
Je vais cibler uniquement Windows 2000 et vers le haut et mon code sera i18n dès le début vers le haut.
La réponse courte: NON.
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 de la 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 des Substituts.
Avec 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.
Je suis d'accord avec Sascha. Le postulat sous-jacent 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 permettra de 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 résultat en char* et wchar_t* des 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 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
(Maintenant, cela peut être une hypothèse valide pour votre logiciel, mais...)
Le web s'exécute sur UTF-8, et une pléthore de plus rares encodages. L' TCHAR concept ne reconnaît que deux: "ANSI" (qui ne peut 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 n'utilise TCHAR. Poco utilise std::string et UTF-8. SQLite est UTF-8 et UTF-16 versions de son API, mais pas d' 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.
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 de l'UTF codages pour les chaînes de caractères: UTF-8 char chaînes et UTF-16 (sur Windows) ou UTF-32 (sur les systèmes de type Unix) wchar_t des chaînes de caractères. typedef UTF16 et UTF32 types de caractères pour éviter les différences de plate-forme.
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.
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.
Dit l' Introduction à la programmation Windows article sur MSDN
Nouvelles applications doivent toujours appeler les versions Unicode (de l’API).
Les macros de texte et TCHAR sont moins utiles aujourd'hui, car toutes les applications doivent utiliser Unicode.
Je m’en tiendrais à et .
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
