c++ - example - ¿Sigue siendo relevante TCHAR?
wchar_t (11)
El artículo de introducción a la programación de Windows en MSDN dice
Las nuevas aplicaciones siempre deben llamar a las versiones Unicode (de la API).
Las macros TEXT y TCHAR son menos útiles hoy en día, ya que todas las aplicaciones deberían usar Unicode.
Me quedaría con wchar_t y L"" .
Soy nuevo en la programación de Windows y después de leer el libro de Petzold me pregunto:
¿sigue siendo una buena práctica usar el tipo TCHAR y la función _T() para declarar cadenas o si simplemente debería usar las wchar_t y L"" en el nuevo código?
Apuntaré solo a Windows 2000 y mi código será i18n desde el inicio.
En mi humilde opinión, si hay TCHAR en tu código, estás trabajando en el nivel incorrecto de abstracción.
Use el tipo de cadena que le resulte más conveniente cuando trabaje con el procesamiento de texto; con suerte, esto será algo que respaldará el Unicode, pero eso depende de usted. Realice la conversión en los límites de la API del sistema operativo según sea necesario.
Al tratar con rutas de archivos, amplíe su propio tipo personalizado en lugar de usar cadenas. Esto le permitirá separadores de ruta independientes del sistema operativo, le ofrecerá una interfaz más sencilla para codificar que la división y concatenación de cadenas manual, y será mucho más fácil de adaptar a diferentes sistemas operativos (ansi, ucs-2, utf-8, lo que sea) .
La respuesta corta: NO .
Como todos los demás ya escribieron, muchos programadores todavía usan TCHAR y las funciones correspondientes. En mi humilde opinión, todo el concepto fue una mala idea . UTF-16 procesamiento de cadenas UTF-16 es muy diferente al simple procesamiento de cadenas ASCII / MBCS. Si utiliza los mismos algoritmos / funciones con ambos (¡en esto se basa la idea de TCHAR!), Obtiene un rendimiento muy malo en la versión UTF-16 si está haciendo un poco más que una simple concatenación de cadenas (como análisis sintáctico, etc.). La razón principal es Surrogates .
Con la única excepción cuando realmente tiene que compilar su aplicación para un sistema que no admite Unicode, no veo razón para usar este equipaje del pasado en una nueva aplicación.
Las únicas razones que veo para usar algo más que el WCHAR explícito son la portabilidad y la eficiencia.
Si desea que su último ejecutable sea lo más pequeño posible, use char.
Si no le importa el uso de la RAM y desea que la internacionalización sea tan fácil como la simple traducción, use WCHAR.
Si desea que su código sea flexible, use TCHAR.
Si solo planea usar los caracteres latinos, también podría usar las cadenas ASCII / MBCS para que su usuario no necesite tanta RAM.
Para las personas que están "empezando desde el principio", sálvate el espacio del código fuente y simplemente utiliza todas las funciones Unicode.
Me gustaría sugerir un enfoque diferente (ninguno de los dos).
Para resumir, use char * y std :: string, suponiendo la codificación UTF-8, y realice las conversiones a UTF-16 solo cuando ajuste las funciones de la API.
Se puede encontrar más información y justificación para este enfoque en los programas de Windows en http://www.utf8everywhere.org .
Si se está preguntando si todavía está en práctica, entonces sí, todavía se usa bastante. Nadie verá su código gracioso si usa TCHAR y _T (""). El proyecto en el que estoy trabajando ahora es la conversión de ANSI a Unicode, y vamos a la ruta portátil (TCHAR).
Sin embargo...
Mi voto sería olvidar todas las macros portátiles ANSI / UNICODE (TCHAR, _T ("") y todas las llamadas a _tXXXXXX, etc.) y simplemente asumir unicode en todas partes. Realmente no veo el sentido de ser portátil si nunca necesitarás una versión ANSI. Usaría todas las funciones y tipos de caracteres anchos directamente. Preprend todos los literales de cadena con una L.
Si, absolutamente; al menos para la macro _T. Aunque no estoy tan seguro sobre las cosas de los personajes anchos.
La razón es para admitir mejor WinCE u otras plataformas Windows no estándar. Si está 100% seguro de que su código permanecerá en NT, entonces probablemente solo pueda usar declaraciones regulares de cadenas C. Sin embargo, es mejor inclinarse por un enfoque más flexible, ya que es mucho más fácil definir esa macro en una plataforma que no sea Windows en comparación con recorrer miles de líneas de código y agregarlas a todas partes en caso de que necesite portar alguna biblioteca. a windows mobile.
Solo agregando a una vieja pregunta:
NO
Inicie un nuevo proyecto CLR C ++ en VS2010. Microsoft mismo usa L"Hello World" , dijo nuff.
TCHAR / WCHAR podría ser suficiente para algunos proyectos heredados. Pero para nuevas aplicaciones, diría NO .
Todos estos productos TCHAR / WCHAR están ahí por razones históricas. TCHAR proporciona una forma clara (disfraz) para cambiar entre codificación de texto ANSI (MBCS) y codificación de texto Unicode (UTF-16). En el pasado, las personas no entendían la cantidad de caracteres de todos los idiomas del mundo. Supusieron que 2 bytes eran suficientes para representar a todos los caracteres y, por lo tanto, tener un esquema de codificación de caracteres de longitud fija utilizando WCHAR. Sin embargo, esto ya no es cierto después del lanzamiento de Unicode 2.0 en 1996 .
Es decir: no importa cuál sea su uso en CHAR / WCHAR / TCHAR, la parte de procesamiento de texto de su programa debe poder manejar caracteres de longitud variable para la internacionalización.
Entonces, realmente necesita hacer más que elegir uno de CHAR / WCHAR / TCHAR para programar en Windows:
- Si su aplicación es pequeña y no implica el procesamiento de texto (es decir, simplemente pasando la cadena de texto como argumentos), entonces quédese con WCHAR. Ya que es más fácil de esta manera trabajar con WinAPI con soporte Unicode.
- De lo contrario, sugeriría usar UTF-8 como codificación interna y almacenar textos en char cadenas o std :: string. Y encubrirlos a UTF-16 cuando se llama a WinAPI. UTF-8 es ahora la codificación dominante y hay muchas bibliotecas y herramientas útiles para procesar cadenas UTF-8.
Consulte este maravilloso sitio web para obtener más información en profundidad: http://utf8everywhere.org/
Tengo que estar de acuerdo con Sascha. La premisa subyacente de TCHAR / _T() / etc. es que puede escribir una aplicación basada en "ANSI" y luego mágicamente darle soporte Unicode definiendo una macro. Pero esto se basa en varias suposiciones malas:
Que construyas activamente versiones de MBCS y Unicode de tu software
De lo contrario, se equivocará y usará cadenas de caracteres comunes en muchos lugares.
Que no use escapes de barra invertida que no sean ASCII en literales _T ("...")
A menos que su codificación "ANSI" sea ISO-8859-1, los literales char* y wchar_t* no representarán los mismos caracteres.
Que las cadenas UTF-16 se usan como cadenas "ANSI"
Ellos no están. Unicode presenta varios conceptos que no existen en la mayoría de las codificaciones de caracteres heredadas. Sustitutos. Combinando personajes. Normalización. Reglas de carcasa condicionales y sensibles al idioma.
Y quizás lo más importante, el hecho de que UTF-16 rara vez se guarda en el disco o se envía a través de Internet: UTF-8 tiende a ser preferido para la representación externa.
Que su aplicación no usa Internet
(Ahora, esta puede ser una suposición válida para su software, pero ...)
La web se ejecuta en UTF-8 y una plétora de codificaciones más raras . El concepto de TCHAR solo reconoce dos: "ANSI" (que no puede ser UTF-8 ) y "Unicode" (UTF-16). Puede ser útil para que sus llamadas a la API de Windows sean compatibles con Unicode, pero no sirve para hacer que sus aplicaciones web y de correo electrónico sean compatibles con Unicode.
Que no usa bibliotecas que no sean de Microsoft
Nadie más usa TCHAR . Poco usa std::string y UTF-8. SQLite tiene versiones UTF-8 y UTF-16 de su API, pero no TCHAR . TCHAR ni siquiera está en la biblioteca estándar, por lo que no std::tcout menos que quiera definirlo usted mismo.
Lo que recomiendo en lugar de TCHAR
Olvide que existen codificaciones "ANSI", excepto cuando necesita leer un archivo que no es válido UTF-8. Olvídate de TCHAR también. Siempre llame a la versión "W" de las funciones de la API de Windows. #define _UNICODE solo para asegurarse de no llamar accidentalmente a una función "A".
Utilice siempre codificaciones UTF para cadenas: UTF-8 para cadenas de caracteres y UTF-16 (en Windows) o UTF-32 (en sistemas tipo Unix) para cadenas wchar_t . tipos de caracteres typedef UTF16 y UTF32 para evitar diferencias en la plataforma.
Todavía usaría la sintaxis de TCHAR si estuviera haciendo un nuevo proyecto hoy. No hay mucha diferencia práctica entre usarlo y la sintaxis de WCHAR, y prefiero el código que es explícito en lo que es el tipo de carácter. Como la mayoría de las funciones de API y objetos auxiliares toman / usan tipos de TCHAR (p. Ej .: CString), tiene sentido usarlo. Además, le brinda flexibilidad si decide usar el código en una aplicación ASCII en algún momento, o si Windows evoluciona a Unicode32, etc.
Si decides ir a la ruta WCHAR, sería explícito al respecto. Es decir, use CStringW en lugar de CString y macros de conversión al convertir a TCHAR (p. Ej .: CW2CT).
Esa es mi opinión, de todos modos.