Existe-t-il des instructions pour la mise à jour des applications C++ Builder pour C++ Builder 2009?

Question

J'ai une gamme d'applications Win32 VCL développées avec C++ Builder à partir de BCB5, et je veux les porter sur ECB2009 ou quoi que ce soit maintenant.

Certaines de mes applications utilisent les anciens composants Unicode TNT/TMS, donc j'ai un bon mélange de AnsiStrings et de WideStrings dans tout le code. La nouvelle version introduit UnicodeString, et un tas de #defines qui changent la façon dont les fonctions comme c_str se comportent. Je souhaite modifier mon code de manière aussi rétrocompatible que possible, afin que la même base de code puisse toujours être compilée et exécutée (de manière non-unicode) sur BCB2007 si nécessaire.

domaines particulièrement préoccupants sont les suivants:

• Passer des chaînes à/de l'API Win32 fonctions
• Interop avec TXMLDocument
• cordes 'brutes' utilisées pour comms RS232, etc.

Plutôt que d'appliquer les changements au couteau et à la fourchette, je cherche des directives que je peux appliquer pour faciliter la migration, tout en gardant une compatibilité descendante dans la mesure du possible.

Si de telles directives n'existent pas déjà, peut-être pouvons-nous en formuler ici?

Answer 1

Le plus gros problème est la compatibilité pour C++ Builder 2009 et les versions précédentes, les différences Unicode sont certaines, mais les fichiers de configuration du projet ont également changé. D'après les discussions que j'ai suivies sur le CodeGear forums, il n'y a pas beaucoup de choix en la matière.

Je pense que le premier endroit pour commencer, si vous ne l'avez pas fait, est le C++Builder 2009 release notes.

La plus grande chose vue a été le mappage TCHAR (à wchar ou char); L'utilisation des variétés de cordes STL peut être utile, car elles ne devraient pas être très différentes entre les deux versions. Le mappage existait également dans C++ Builder 2007 (avec l'en-tête tchar).

Answer 2

Pour tout code qui n'a pas besoin d'être explicitement Ansi ou explicite Unicode, vous devriez envisager d'utiliser les types System :: String, System :: Char et System :: PChar autant que possible. Cela facilitera beaucoup de migration, et ils fonctionnent dans les versions précédentes. Lorsque vous passez un System :: String à une fonction API, vous devez prendre en compte le nouveau paramètre "TCHAR maps to" dans les options Project. Si vous essayez de transmettre AnsiString :: c_str() lorsque "TCHAR correspond à" est défini sur "wchar_t" ou UnicodeString :: c_str() lorsque "TCHAR correspond à" est défini sur "char", vous devrez effectuer typecasts. Si vous avez "TCHAR maps to" défini sur "wchar_t". Techniquement, UnicodeString :: t_str() fait la même chose que TCHAR dans l'API, mais t_str() peut être très dangereux si vous en abusez (quand "TCHAR maps to" est défini sur "char", t_str() transforme le Données internes d'UnicodeString à Ansi). Pour les chaînes "brutes", vous pouvez utiliser le nouveau type RawByteString (bien que je ne le recommande pas), ou TBytes à la place (qui est un tableau d'octets - recommandé). Vous ne devriez pas utiliser Ansi/Wide/UnicodeString pour les données sans caractère pour commencer. La plupart des gens utilisaient AnsiString comme tampon de données de fortune dans les versions précédentes. Ne fais plus ça. Ceci est particulièrement important car AnsiString prend désormais en charge les pages de codes et vos données peuvent donc être converties en d'autres pages de code lorsque vous y attendez le moins.