Gibt es Richtlinien zum Aktualisieren von C++ Builder-Anwendungen für C++ Builder 2009?

Question

Ich habe eine Reihe von Win32 VCL-Anwendungen, die mit C++ Builder ab BCB5 entwickelt wurden, und möchten sie nach ECB2009 oder wie auch immer es jetzt heißt, portieren.

Einige meiner Anwendungen verwenden die alten TNT/TMS-Unicode-Komponenten, daher habe ich im gesamten Code eine gute Mischung aus AnsiStrings und WideStrings. Die neue Version führt UnicodeString und eine Reihe von #defines ein, die die Funktionsweise von c_str verändern.

Ich möchte meinen Code so rückwärtskompatibel wie möglich ändern, damit die gleiche Codebasis noch kompiliert und (falls nicht Unicode) auf BCB2007 ausgeführt werden kann.

Besondere Bereiche sind:

• Passing Strings zu/von Win32-API-Funktionen
• Interop mit TXMLDocument
• 'Raw' Strings für RS232 Comms, etc. verwendet

Anstatt die Änderungen zu modifizieren, suche ich nach Richtlinien, die ich anwenden kann, um die Migration zu erleichtern und gleichzeitig die Abwärtskompatibilität zu wahren, wo immer es möglich ist.

Wenn keine solchen Richtlinien bereits existieren, können wir vielleicht einige hier formulieren?

Answer 1

Das größte Problem ist die Kompatibilität für C++ Builder 2009 und früheren Versionen, die Unicode-Unterschiede sind einige, aber die Projektkonfigurationsdateien haben sich ebenfalls geändert. Von den Diskussionen, die ich auf dem CodeGear forums verfolgt habe, gibt es nicht eine ganze Menge Auswahl in der Sache.

Ich denke, der erste Ort zu starten, wenn Sie dies noch nicht getan haben, ist die C++Builder 2009 release notes.

Die größte Sache gesehen wurde die TCHAR-Zuordnung (zu wchar oder char); Die Verwendung der STL-String-Varietäten kann eine Hilfe sein, da sie zwischen den beiden Versionen nicht sehr unterschiedlich sein sollten. Die Zuordnung existierte auch in C++ Builder 2007 (mit dem Tchar-Header).

Answer 2

Für jeden Code, der nicht explizit Ansi oder explizit Unicode sein muss, sollten Sie die System :: String, System :: Char und System :: PChar typedefs so viel wie möglich verwenden. Dies erleichtert die Migration und sie funktionieren in früheren Versionen.

Wenn Sie eine System :: String an eine API-Funktion übergeben, müssen Sie die neue Einstellung "TCHAR Maps to" in den Projektoptionen berücksichtigen. Wenn Sie versuchen, AnsiString :: c_str() zu übergeben, wenn "TCHAR maps to" auf "wchar_t" festgelegt ist, oder UnicodeString :: c_str(), wenn "TCHAR maps to" auf "char" gesetzt ist, müssen Sie die entsprechenden Schritte ausführen Typumwandlungen. Wenn Sie "TCHAR Maps to" auf "wchar_t" eingestellt haben. Technisch gesehen macht UnicodeString :: t_str() dasselbe wie TCHAR in der API, aber t_str() kann sehr gefährlich sein, wenn Sie es missbrauchen (wenn "TCHAR maps to" auf "char" gesetzt ist, transformiert t_str() das UnicodeString interne Daten zu Ansi).

Für "rohe" Strings können Sie den neuen RawByteString-Typ verwenden (obwohl ich es nicht empfehle), oder stattdessen TBytes (was ein Array von Bytes ist - empfohlen). Sie sollten Ansi/Wide/UnicodeString nicht für Nicht-Zeichendaten verwenden. Die meisten Leute verwendeten AnsiString als provisorische Datenpuffer in früheren Versionen. Tu das nicht mehr. Dies ist besonders wichtig, da AnsiString nun Codepage-fähig ist und Ihre Daten daher möglicherweise in andere Codepages konvertiert werden, wenn Sie es am wenigsten erwarten.