Существуют ли инструкции по обновлению приложений C++ Builder для C++ Builder 2009?
У меня есть ряд приложений Win32 VCL, разработанных с помощью C++ Builder начиная с BCB5, и я хочу перенести их на ECB2009 или как там он сейчас называется.
Некоторые из моих приложений используют старые компоненты Unicode TNT / TMS, поэтому во всем коде у меня хорошее сочетание AnsiStrings и WideStrings. Новая версия представляет UnicodeString и набор #defines, которые изменяют поведение таких функций, как c_str.
Я хочу изменить свой код таким образом, чтобы он был как можно более обратно совместимым, чтобы та же база кода все еще могла быть скомпилирована и запущена (не в формате Unicode) на BCB2007, если это необходимо.
Особую озабоченность вызывают следующие области:
- Передача строк в / из Win32 API функции
- Взаимодействие с TXMLDocument
- «Необработанные» строки, используемые для связи RS232 и т. д.
Вместо того, чтобы раздумывать над изменениями, я ищу рекомендации, которые я могу применить, чтобы упростить миграцию, сохраняя при этом обратную совместимость везде, где это возможно.
Если таких руководящих принципов еще нет, может быть, мы сможем сформулировать некоторые здесь?
Ответы 2
Самая большая проблема - совместимость с C++ Builder 2009 и предыдущими версиями, различия в Unicode есть, но файлы конфигурации проекта также изменились. Судя по обсуждениям, за которыми я следил по Форумы CodeGear, в этом вопросе не так уж много вариантов.
Я думаю, что первое, с чего следует начать, если вы еще не сделали этого, - это Заметки о выпуске C++ Builder 2009.
Самым большим из замеченных явлений было отображение TCHAR (в wchar или char); использование разновидностей строк STL может оказаться полезным, поскольку они не должны сильно отличаться между двумя версиями. Отображение существовало и в C++ Builder 2007 (с заголовком tchar).
Для любого кода, который не обязательно должен быть явно Ansi или явно Unicode, вам следует подумать об использовании typedefs System :: String, System :: Char и System :: PChar в максимально возможной степени. Это поможет упростить миграцию, и они работают в предыдущих версиях.
При передаче System :: String в функцию API вы должны принять во внимание новую настройку «TCHAR maps to» в параметрах проекта. Если вы попытаетесь передать AnsiString :: c_str (), когда «TCHAR сопоставляет с» установлен на «wchar_t», или UnicodeString :: c_str (), когда «TCHAR сопоставляет с» установлен на «char», вам придется выполнить соответствующие приведение типов. Если у вас есть «TCHAR maps to», установите значение «wchar_t». Технически UnicodeString :: t_str () делает то же самое, что и TCHAR в API, однако t_str () может быть очень опасным при неправильном использовании (когда для параметра «TCHAR maps to» установлено значение «char», t_str () преобразует Внутренние данные UnicodeString в Ansi).
Для «сырых» строк вы можете использовать новый тип RawByteString (хотя я не рекомендую его) или вместо этого TBytes (который является массивом байтов - рекомендуется). Вы не должны использовать Ansi / Wide / UnicodeString для несимвольных данных для начала. Большинство людей использовали AnsiString как временные буферы данных в прошлых версиях. Не делай этого больше. Это особенно важно, потому что AnsiString теперь поддерживает кодовые страницы, и поэтому ваши данные могут быть преобразованы в другие кодовые страницы, когда вы меньше всего этого ожидаете.