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

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

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

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

Особую озабоченность вызывают:

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

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

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


unicode vcl c++builder
person Roddy    schedule 30.09.2008    source источник

Ответы (2)


arrow_upward
4
arrow_downward

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

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

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

person Community    schedule 30.09.2008

arrow_upward
2
arrow_downward

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

При передаче System::String в функцию API необходимо учитывать новую настройку «TCHAR maps to» в параметрах проекта. Если вы попытаетесь передать AnsiString::c_str(), когда "TCHAR maps to" имеет значение "wchar_t", или UnicodeString::c_str(), когда для "TCHAR maps to" установлено значение "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 теперь поддерживает кодовую страницу, и поэтому ваши данные могут быть преобразованы в другие кодовые страницы, когда вы меньше всего этого ожидаете.

person Remy Lebeau    schedule 04.06.2009