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

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

6 голосов
/ 30 сентября 2008

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

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

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

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

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

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

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

Ответы [ 2 ]

4 голосов
/ 30 сентября 2008

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

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

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

2 голосов
/ 04 июня 2009

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

При передаче System :: String в функцию API необходимо учитывать новую настройку «TCHAR map 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 теперь поддерживает кодовые страницы, и поэтому ваши данные могут быть преобразованы в другие кодовые страницы, когда вы меньше всего этого ожидаете.

...