¿Existen directrices para actualizar las aplicaciones de C++ Builder para C++ Builder 2009?

Question

Tengo una gama de aplicaciones para Win32 VCL desarrolladas con C++ Builder desde BCB5 en adelante, y quiero portarlas a ECB2009 o como se llame ahora.

Algunas de mis aplicaciones usan los viejos componentes TNT/TMS Unicode, así que tengo una buena combinación de AnsiStrings y WideStrings en todo el código. La nueva versión presenta UnicodeString y un grupo de #defines que cambian la forma en que funcionan las funciones como c_str.

Quiero modificar mi código de una manera que sea lo más compatible posible con versiones anteriores, de modo que la misma base de código aún se pueda compilar y ejecutar (de manera no unicode) en BCB2007 si es necesario.

áreas particulares de interés son:

• cadenas Pasando a/de la API de Win32 funciones
• interoperabilidad con TXMLDocument
• cuerdas 'en bruto' se utilizan para comunicaciones RS232, etc.

En lugar de los cambios a cuchillo y horquilla, estoy buscando pautas que pueda aplicar para facilitar la migración, manteniendo compatibilidad hacia atrás siempre que sea posible.

Si ya no existen tales directrices, tal vez podamos formular algunas aquí?

Answer 1

El mayor problema es la compatibilidad de C++ Builder 2009 y las versiones anteriores, las diferencias Unicode son algunas, pero los archivos de configuración del proyecto también han cambiado. De las discusiones que he estado siguiendo en el CodeGear forums, no hay muchas opciones en el asunto.

Creo que el primer lugar para comenzar, si no lo ha hecho, es el C++Builder 2009 release notes.

Lo más importante que se ha visto ha sido el mapeo TCHAR (a wchar o char); usar las variedades de cuerdas STL puede ser una ayuda, ya que no deberían ser muy diferentes entre las dos versiones. La asignación también existía en C++ Builder 2007 (con el encabezado tchar).

Answer 2

Para cualquier código que no tenga que ser explícitamente explícito o explícitamente Unicode, debería considerar usar SystemDama, System :: Char y System :: PChar typedefs tanto como sea posible. Eso ayudará a facilitar una gran cantidad de migración, y funcionan en versiones anteriores.

Al pasar un System :: String a una función API, debe tener en cuenta la nueva configuración "TCHAR maps to" en las opciones del proyecto. Si intenta pasar AnsiString :: c_str() cuando "TCHAR se asigna a" se establece en "wchar_t", o UnicodeString :: c_str() cuando "TCHAR se asigna a" se establece en "char", tendrá que realizar las operaciones apropiadas. typecasts. Si tiene "mapas TCHAR a" configurado en "wchar_t". Técnicamente, UnicodeString :: t_str() hace lo mismo que TCHAR en la API, sin embargo t_str() puede ser muy peligroso si lo usa mal (cuando "TCHAR se asigna a" se establece en "char", t_str() transforma el Datos internos de UnicodeString a Ansi).

Para cadenas "en bruto", puede usar el nuevo tipo RawByteString (aunque no lo recomiendo) o TBytes en su lugar (que es una matriz de bytes - recomendado). No debe usar Ansi/Wide/UnicodeString para datos que no sean de carácter, para empezar. La mayoría de las personas usaba AnsiString como almacenamientos intermedios de datos improvisados ​​en versiones anteriores. No hagas más eso. Esto es particularmente importante porque AnsiString ahora es consciente de la página de códigos y, por lo tanto, sus datos podrían convertirse a otras páginas de códigos cuando menos lo espere.