¿TCHAR sigue siendo relevante?

Question

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 debo usar wchar_t y L " " cadenas en código nuevo?

Me dirigiré solo a Windows 2000 y superior y mi código será i18n desde el inicio .

Answer 1

Todavía usaría la sintaxis de TCHAR si estuviera haciendo un nuevo proyecto hoy. No hay mucha diferencia práctica entre usarla y la sintaxis de WCHAR, y prefiero el código que es explícito en lo que es el tipo de carácter. Dado que la mayoría de las funciones de la API y los objetos auxiliares toman / usan los tipos TCHAR (por ejemplo, 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 alguna vez 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 convierta macros al convertir a TCHAR (por ejemplo: CW2CT).

Esa es mi opinión, de todos modos.

Answer 2

La respuesta corta: NO .

Como todos los otros que 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 el procesamiento de cadenas es muy diferente de la cadena ASCII / MBCS simple tratamiento. Si utiliza los mismos algoritmos / funciones con ambos (¡en esto se basa la idea de TCHAR!), Obtendrá 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, etc.). La razón principal son Sustitutos .

Con la única excepción cuando realmente tiene que compilar su aplicación para un sistema que no es compatible con Unicode, no veo ninguna razón para usar este equipaje del pasado en una nueva aplicación.

Answer 3

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 brindarle soporte Unicode definiendo una macro . Pero esto se basa en varios supuestos erróneos:

Que construyas activamente las versiones MBCS y Unicode de tu software

De lo contrario, usted se deslizará y usará cadenas comunes char * en muchos lugares.

Que no uses escapes de barra invertida que no sean ASCII en _T (" ... ") literales

A menos que tu " ANSI " la codificación pasa a ser ISO-8859-1, los literales char * y wchar_t * resultantes no representarán los mismos caracteres.

Que las cadenas UTF-16 se usan como " ANSI " cadenas

No lo son. Unicode introduce 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 tu aplicación no utiliza Internet

(Ahora, esto puede ser una suposición válida para el software su , pero ...)

La web se ejecuta en UTF-8 y una plétora de codificaciones más raras . El concepto TCHAR solo reconoce dos: " ANSI " (que no puede ser UTF-8 ) y " Unicode " (UTF-16). Puede ser útil para hacer que sus llamadas API de Windows sean compatibles con Unicode, pero es inútil para hacer que sus aplicaciones web y de correo electrónico sean compatibles con Unicode.

Que no uses bibliotecas que no sean de Microsoft

Nadie más usa TCHAR . Poco utiliza 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, así que no hay std :: tcout a menos que desee definirlo usted mismo.

Lo que recomiendo en lugar de TCHAR

Olvida que " ANSI " Existen codificaciones, excepto cuando necesita leer un archivo que no es válido en UTF-8. Olvídate de TCHAR también. Siempre llame al " W " Versión de las funciones API de Windows. #define _UNICODE solo para asegurarte de no llamar accidentalmente a " A " función.

Utilice siempre codificaciones UTF para cadenas: UTF-8 para cadenas char y UTF-16 (en Windows) o UTF-32 (en sistemas similares a Unix) para wchar_t cuerdas. typedef UTF16 y UTF32 para evitar diferencias de plataforma.

Answer 4

Si te estás 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 se está convirtiendo de ANSI a Unicode, y vamos por la ruta portátil (TCHAR).

However...

Mi voto sería olvidar todas las macros portátiles ANSI / UNICODE (TCHAR, _T (" "), y todas las llamadas _tXXXXXX, etc ...) y simplemente asumir unicode en todas partes. Realmente no veo el punto de ser portátil si nunca necesitarás una versión ANSI. Usaría todas las funciones y tipos de caracteres anchos directamente. Interprete todos los literales de cadena con una L.

Answer 5

El Introducción al artículo de programación de Windows en MSDN dice

  

Las nuevas aplicaciones siempre deben llamar a las versiones Unicode (de la API).

     

Las macros TEXTO y TCHAR son menos útiles hoy en día, porque todas las aplicaciones deben usar Unicode.

Me quedaría con wchar_t y L " " .

Answer 6

Me gustaría sugerir un enfoque diferente (ninguno de los dos).

Para resumir, use char * y std :: string, asumiendo la codificación UTF-8, y realice las conversiones a UTF-16 solo cuando ajuste las funciones de la API.

Puede encontrar más información y justificación de este enfoque en los programas de Windows en http://www.utf8everywhere.org .

Answer 7

TCHAR / WCHAR podría ser suficiente para algunos proyectos heredados. Pero para nuevas aplicaciones, diría NO .

Todas estas cosas TCHAR / WCHAR están ahí por razones históricas. TCHAR proporciona una manera aparentemente ordenada (disfrazada) de cambiar entre la codificación de texto ANSI (MBCS) y la codificación de texto Unicode (UTF-16). En el pasado, la gente no entendía el número de caracteres de todos los idiomas del mundo. Asumieron que 2 bytes eran suficientes para representar todos los caracteres y, por lo tanto, tenían un esquema de codificación de caracteres de longitud fija utilizando WCHAR . Sin embargo, esto ya no se cumple después del lanzamiento de Unicode 2.0 en 1996 .

Es decir: Independientemente de lo que use en CHAR / WCHAR / TCHAR , la parte de procesamiento de texto en su programa debe poder manejar longitud variable caracteres para la internacionalización.

Por lo tanto, realmente necesita hacer algo más que elegir uno de CHAR / WCHAR / TCHAR para la programación en Windows:

1. Si su aplicación es pequeña y no implica procesamiento de texto (es decir, simplemente pasar la cadena de texto como argumentos), entonces siga con WCHAR . Como es más fácil trabajar con WinAPI con soporte Unicode.
2. De lo contrario, sugeriría usar UTF-8 como codificación interna y almacenar textos en cadenas de caracteres o std :: string. Y encubrirlos a UTF-16 cuando llame a WinAPI. UTF-8 es ahora la codificación dominante y hay muchas bibliotecas y herramientas útiles para procesar cadenas UTF-8.

Echa un vistazo a este maravilloso sitio web para leer más a fondo: http://utf8everywhere.org/

Answer 8

Sí, absolutamente; al menos para la macro _T. Sin embargo, no estoy tan seguro de las cosas de carácter ancho.

La razón es que es mejor admitir WinCE u otras plataformas Windows no estándar. Si está 100% seguro de que su código permanecerá en NT, entonces es probable que solo pueda usar declaraciones de cadena C regulares. Sin embargo, es mejor tender hacia un enfoque más flexible, ya que es mucho más fácil #definir esa macro en una plataforma que no es Windows en comparación con pasar por miles de líneas de código y agregarlo a todas partes en caso de que necesite portar alguna biblioteca a windows mobile.

Answer 9

En mi humilde opinión, si hay TCHAR en su código, está trabajando en el nivel de abstracción incorrecto.

Usar el tipo de cadena cualquiera que sea es más conveniente para usted cuando se trata con el procesamiento de texto; es de esperar que esto sea algo compatible con Unicode, pero eso depende de usted. Realice la conversión en los límites de la API del sistema operativo según sea necesario.

Cuando trabaje con rutas de archivos, cree su propio tipo personalizado en lugar de usar cadenas. Esto le permitirá los separadores de ruta independientes del sistema operativo, le brindará una interfaz más fácil de codificar que la concatenación y divisió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) .

Answer 10

Las únicas razones que veo para usar algo que no sea el WCHAR explícito son la portabilidad y la eficiencia.

Si desea que su archivo ejecutable final sea lo más pequeño posible, utilice char.

Si no le importa el uso de RAM y desea que la internacionalización sea tan fácil como una simple traducción, use WCHAR.

Si desea que su código sea flexible, use TCHAR.

Si solo planeas usar los caracteres latinos, también puedes usar las cadenas ASCII / MBCS para que tu usuario no necesite tanta RAM.

Para las personas que están " i18n desde el inicio " ;, ahórrese el espacio del código fuente y simplemente use todas las funciones de Unicode.

Answer 11

Solo agregando a una vieja pregunta:

NO

Ir a iniciar un nuevo proyecto CLR C ++ en VS2010. Los propios Microsoft usan L " Hello World " ', dijo nuff.