Существуют ли рекомендации по обновлению приложений C++Builder для C++Builder 2009?

Question

У меня есть ряд приложений Win32 VCL, разработанных с помощью C++Builder начиная с BCB5 и далее, и я хочу перенести их на ECB2009 или как там его сейчас называют.

Некоторые из моих приложений используют старые компоненты Unicode TNT/TMS, поэтому у меня есть хорошее сочетание AnsiStrings и WideStrings во всем коде. В новой версии представлен UnicodeString и несколько #defines, которые изменяют поведение таких функций, как c_str.

Я хочу изменить свой код так, чтобы он был как можно более обратно-совместимым, чтобы при необходимости можно было скомпилировать и запустить ту же самую кодовую базу (не в юникодном режиме) на BCB2007.

Особые проблемные области:

• Передача строк в / из функций Win32 API
• Взаимодействие с TXMLDocument
• "Сырые" строки, используемые для связи RS232 и т. Д.

Вместо того, чтобы вносить изменения, я ищу рекомендации, которые можно применить, чтобы упростить миграцию, сохраняя обратную совместимость, где это возможно.

Если таких рекомендаций уже не существует, может быть, мы сможем сформулировать некоторые из них здесь?

Answer 1

Самая большая проблема - это совместимость с C++Builder 2009 и предыдущими версиями, различия в Юникоде некоторые, но файлы конфигурации проекта также изменились. Из обсуждений, за которыми я следил на форумах CodeGear, в этом вопросе не так много вариантов.

Я думаю, что первым делом, если вы этого не сделали, являются заметки о выпуске C++Builder 2009.

Самая большая вещь, которую можно увидеть, это отображение TCHAR (на wchar или char); может помочь использование строковых разновидностей STL, так как они не должны сильно различаться между двумя версиями. Сопоставление существовало и в C++Builder 2007 (с заголовком tchar).

Answer 2

Для любого кода, который не обязательно должен быть явно Ansi или явно Unicode, вам следует рассмотреть возможность максимально возможного использования typedefs System::String, System::Char и System::PChar. Это поможет облегчить миграцию, и они работают в предыдущих версиях.

При передаче System:: String в функцию API необходимо учитывать новый параметр "TCHAR maps to" в параметрах проекта. Если вы попытаетесь передать AnsiString::c_str(), когда для "TCHAR map to" установлено значение "wchar_t", или для UnicodeString::c_str(), если для "TCHAR map to" установлено значение "char", вам придется выполнить соответствующие приведения типов. Если у вас есть "TCHAR maps to", установите "wchar_t". Технически, UnicodeString::t_str() делает то же самое, что и TCHAR в API, однако t_str () может быть очень опасным, если вы его неправильно используете (когда "TCHAR сопоставляется с" установлено в "char", t_str() преобразует Внутренние данные UnicodeString в Ansi).

Для "сырых" строк вы можете использовать новый тип RawByteString (хотя я не рекомендую его) или TBytes (который является массивом байтов - рекомендуется). Вы не должны использовать Ansi/Wide/UnicodeString для не символьных данных для начала. Большинство людей использовали AnsiString в качестве временных буферов данных в прошлых версиях. Не делай этого больше. Это особенно важно, потому что AnsiString теперь поддерживает кодовые страницы, и поэтому ваши данные могут быть преобразованы в другие кодовые страницы, когда вы меньше всего этого ожидаете.