2009-08-27 16 views
5

yo estoy en el proceso de aprendizaje de C++ y encontré un artículo sobre el MSDN aquí:¿Qué usa Microsoft como tipo de datos para cadenas Unicode?

http://msdn.microsoft.com/en-us/magazine/dd861344.aspx

En el primer ejemplo de código de la una sola línea de código que mi pregunta se refiere a es la siguiente:

VERIFY(SetWindowText(L"Direct2D Sample")); 

Más específicamente ese prefijo L. He leído un poco y me corrijo si estoy equivocado :-), pero esto es para permitir cadenas de caracteres unicode, es decir, para preparar un juego de caracteres largo. Ahora en durante mi leer sobre esta me encontré con otro artículo sobre Técnicas Adavnced cadena en C aquí http://www.flipcode.com/archives/Advanced_String_Techniques_in_C-Part_I_Unicode.shtml

Se dice que hay un par de opciones, entre ellas la inclusión de la cabecera:

#define UNICODE 

O

#define _UNICODE 

en C, una vez más señalo si estoy equivocado, agradezco sus comentarios. Además se muestra el tipo de datos adecuado por ser estas cadenas Unicode:

wchar_t 

Se arroja al mezclar una macro y una especie de tipo de datos híbrido, el ser macro:

_TEXT(t) 

que simplemente se antepone la cadena con la L y el tipo de datos híbrida como

TCHAR 

la cual recuerda que permitirá unicode si la cabecera está ahí y si no ASCII. Ahora mi pregunta es, o más de una suposición que me gustaría confirmar, que Microsoft usaría este tipo de datos TCHAR que es más flexible o que hay algún beneficio al comprometerse a usar el wchar_t.

También cuando digo que Microsoft usa esto, más específicamente para exmaple en las bibliotecas ATL y WTL, ¿alguien de ustedes tiene preferencia o tiene algún consejo al respecto?

Saludos,

Andrew

+0

Gracias por la respuesta de todos. ¡Lo aprecio! :-) –

Respuesta

12

Para cualquier software nuevo, se deben definir UNICODE y utilizar wchar_t directamente. El uso de ANSI stirngs volverá a perseguirte.

Solo debe usar wchar_t y las versiones anchas de todas las funciones CRT (por ejemplo, wcscmp en lugar de strcmp). Las macros TEXT y TCHAR, etc. solo existen si su código necesita funcionar en entornos ANSI y UNICODE, lo que siento que el código rara vez tiene que hacer.

Cuando crea una nueva aplicación de Windows utilizando Visual Studio, UNICODE se define automáticamente y wchar_t funcionará como un built-in.

1

TCHAR cambia su tipo dependiendo de si se define UNICODE, y se debe usar cuando se desea código que se puede compilar para Unicode y no Unicode.

Si desea procesar explícitamente solo datos UNICODE, puede usar wchar_t.

5

Respuesta corta: la infraestructura híbrida con el tipo TCHAR, la _TEXT() macro y los diversos _t* funciones (_tcscpy viene a la mente) son un retroceso a los tiempos en que Microsoft tenía dos plataformas coexistentes:

  1. Windows La línea NT se basó en la representación de cadena Unicode
  2. La línea de Windows 95/98/ME se basó en la representación de cadena ANSI.

La representación de cadenas aquí significa que todas las API de Windows que esperaban o devolvieron cadenas a su aplicación usaban una u otra representación para estas cadenas. COM agregó aún más confusión, ya que estaba disponible en ambas plataformas, ¡y esperaba cadenas Unicode en ambas!

En aquellos viejos tiempos se recomendaba que escribiera código "portátil": se le indicó que utilice la infraestructura híbrida para sus cadenas para que pueda compilar para ambos modelos simplemente definiendo/indefiniendo UNICODE y/o _UNICODE para su aplicación

Como la línea de Windows9x no es más relevante (para la gran mayoría de las aplicaciones de todos modos) puede ignorar el mundo ANSI y usar las cadenas Unicode directamente.

Tenga en cuenta que Unicode tiene múltiples representaciones hoy en día: como se señaló anteriormente, la convención Unicode implícita en wchar_t es la representación UCS-2 (todos los caracteres codificados en palabras de 16 bits). Hay otras representaciones ampliamente utilizadas donde esto no es necesariamente cierto.

Cuestiones relacionadas