Что мне нужно знать, чтобы обновить сложное приложение с C++Builder 2007 до 2010?

Основное приложение моей компании в основном написано на C++ (с некоторым кодом и компонентами Delphi). Мы обновляем RAD Studio 2007 до 2010 до следующей версии, которая начнется примерно через неделю. Что мне нужно знать, чтобы это обновление прошло гладко?

До сих пор я думал о следующих моментах:

  • Unicode. Это выглядит действительно сложно. Наше приложение содержит ужасную смесь std::string-s и AnsiString-s с приведением к ним и из них. У меня много вопросов по этому поводу, таких как "wstring способен удерживать все, что может UnicodeString, и мы должны просто выполнить поиск / замену", или "следует ли нам вообще избегать всех типов строк C++ и использовать UnicodeString", "можем ли мы измените все обработчики событий на использование String, хотя существующие прототипы методов обработчика событий .HPPs были переведены компилятором в AnsiString", вплоть до базовых принципов, таких как" следует ли нам префиксировать все строки с помощью L или достаточно ли умен компилятор с включенным Unicode для использования Unicode-строки "и т. Д. Любое понимание этого было бы очень полезно.

    Нам также нужна обратная совместимость. Наше приложение использует собственный двоичный формат кортежей, который в настоящее время хранит строки в виде массива байтов. Мне нужно обновить это, чтобы читать старые файлы и, по-видимому, писать новые строки Unicode. Как мне обработать строки Unicode, встроенные в двоичном формате? Есть ли какой-нибудь общий способ, где я могу указать UnicodeString на массив байтов, который может быть изначально записан как байты ANSI или Unicode, и он выяснит, что это такое?

  • Сторонние компоненты. В основном мы используем SpTBX, и он выглядит совместимым.

  • Обновления проекта. Стандартный совет на форумах Codegear, похоже, заключается в том, чтобы вручную обновлять все файлы проекта при обновлении. Это огромная работа (7 проектов (в основном libs) в нашем основном приложении, плюс полдюжины DLL, много файлов.) Есть ли способ автоматизировать это?

  • Как выглядит компоновщик? У нас традиционно много проблем с компоновщиком, который случайно зависает или исчерпывает ресурсы, хотя в 2007 году он стал намного лучше. Это одна из причин, по которой наше основное приложение разделено на несколько библиотек - компоновщик не может (надеюсь, что) не смог, а теперь можно "?) справиться иначе.

  • Я знаю, что есть новый редактор и формат библиотеки типов (он хранит IDL, то есть текст, и динамически генерирует TLB?) Насколько хорошо это обрабатывает обновление существующих проектов COM с помощью TLB? У нас есть код Delphi и TLB, которые встроены в приложение C++.

  • Есть ли что-то еще, что я должен рассмотреть или знать?

Я нашел:

Источник

4 ответа

Решение

Обновления проекта. Стандартный совет на форумах Codegear, похоже, заключается в том, чтобы вручную обновлять все файлы проекта при обновлении. Это огромная работа (7 проектов (в основном libs) в нашем основном приложении, плюс полдюжины DLL, много файлов.) Есть ли способ автоматизировать это?

Есть: просто используйте импортер проекта IDE:)
Серьезно, я бы просто попытался импортировать проекты, а затем занялся расследованием, если это не сработало.

Как выглядит компоновщик? У нас традиционно много проблем с компоновщиком, который случайно зависает или исчерпывает ресурсы, хотя в 2007 году он стал намного лучше. Это одна из причин, по которой наше основное приложение разделено на несколько библиотек - компоновщик не может (надеюсь, что) не смог, а теперь можно "?) справиться иначе.

У меня больше не было проблем с ILINK со времен C++Builder 2009. Я иногда читал, что у других возникали ошибки нехватки памяти, но кто-то в группах новостей обнаружил обходной путь:

https://forums.embarcadero.com/thread.jspa?messageID=140012&tstart=0

Кроме того, как вы можете прочитать здесь, компилятор получил новую опцию (-Cx) для управления максимальным объемом памяти, которую он выделяет.

Я знаю, что есть новый редактор и формат библиотеки типов (он хранит IDL, то есть текст, и динамически генерирует TLB?) Насколько хорошо это обрабатывает обновление существующих проектов COM с помощью TLB?

Должно работать безотказно.

У меня много вопросов по этому поводу, таких как "wstring способен хранить все, что может UnicodeString, и мы должны просто выполнить поиск / замену"

Да, на платформах Windows wchar_t обычно имеет размер 16 бит, что означает, что для хранения UTF-16 достаточно того, что и UnicodeString.

или "мы должны избегать всех строковых типов C++ в целом и использовать UnicodeString"

Зависит от того, насколько переносимым должен быть ваш код. В любом случае, когда вам просто нужен строковый тип, используйте "String", а не "UnicodeString".

"Можем ли мы изменить все обработчики событий на использование String, хотя существующие.HPP были переведены компилятором в AnsiString"

Во-первых, вы НИКОГДА не должны повторно использовать файлы.hpp, созданные в старых версиях DCC! Для обработчиков событий, которые используют тип String в Delphi, вы должны использовать UnicodeString. Как и выше, просто используйте "String", и ваш код будет работать как для ANSI, так и для Unicode-версий C++Builder.

вплоть до таких основ, как "должны ли мы префиксировать все строки буквой L, или компилятор достаточно умен с включенным Unicode для использования строк Unicode"

Компилятор не конвертирует ваши строки (это будет противоречить языковым стандартам), но и AnsiString, и UnicodeString имеют перегрузки конструктора копирования для строковых литералов char* и wchar_t*. Т.е. будет работать следующее:

AnsiString as = L"foo";
UnicodeString us = "bar";

Что не будет работать таким образом, так это весь набор функций printf()/scanf(); AnsiString::sprintf() принимает const char*, UnicodeString::sprintf() принимает const wchar_t*.

Если вы часто используете sprintf (), вам может пригодиться моя библиотека CbdeFormat; просто прочитайте мою статью на эту тему.

Источник

Unicode. Это выглядит действительно сложно. Наше приложение содержит ужасную смесь std::string-s и AnsiString-s с приведением к ним и из них. У меня много вопросов по этому поводу, таких как "wstring способен хранить все, что может UnicodeString, и мы должны просто выполнить поиск / замену"

std::wstring содержит wchar_t* строки, как System::UnicodeString делает.

мы должны избегать всех строковых типов C++ в целом и использовать UnicodeString

Это решать вам. char* строки по-прежнему поддерживаются. Вы не обязаны мигрировать все в Unicode.

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

Нет, вы не можете изменить автоматически управляемые обработчики событий для использования System::String псевдоним. Все версии IDE будут жаловаться на это. Вам придется вручную обновить объявления и реализации обработчика событий, чтобы использовать UnicodeString параметры вместо AnsiString параметры при необходимости. Это также означает, что вы также не можете обмениваться файлами DFM и Unit .h между несколькими версиями IDE (что вам не следует делать в любом случае).

мы должны префикс всех строк с L, или компилятор достаточно умен с Unicode включен, чтобы использовать строки Unicode

Нет. Если вы объявите строковую константу или символьную константу без префикса L, данные все равно будут интерпретироваться как Ansi. Это не изменилось. Однако вы можете передать данные Ansi System::UnicodeString (но не до std::wstring), и он автоматически преобразуется в Unicode. Но вы должны быть осторожны, потому что он будет использовать кодовую страницу Ansi по умолчанию для интерпретации данных. Пока ваши данные Ansi используют только символы ASCII, вы будете в порядке. В противном случае, если вы используете не-ASCII символы, вам лучше поместить данные в System::AnsiStringT или же System::RawByteString (оба были введены в CB2009), которому была назначена правильная кодовая страница, а затем назначьте ее System::UnicodeString переменная. Связанная кодовая страница будет использоваться вместо кодовой страницы по умолчанию ОС для преобразования.

Нам также нужна обратная совместимость. Наше приложение использует собственный двоичный формат кортежей, который в настоящее время хранит строки в виде массива байтов. Мне нужно обновить это, чтобы читать старые файлы и, по-видимому, писать новые строки Unicode. Как мне обработать строки Unicode, встроенные в двоичном формате?

Если ваш кортеж ожидает 8-битные символы, то вам нужно убедиться, что любые объявления структуры и тому подобное используют char и не wchar_t персонажи. Если вам нужно хранить строки Unicode, но необходимо поддерживать 8-битную совместимость, то сначала вы должны закодировать строки Unicode в UTF-8 (вы можете использовать System::UTF8String тип строки, чтобы помочь вам - начиная с CB2009, теперь это настоящая строка UTF-8). Пока вы не используете символы не ASCII, ваши старые приложения не будут знать разницу, так как символы ASCII кодируются как есть в UTF-8. Однако если вы хотите хранить необработанные данные Unicode, тогда вашему кортежу понадобится где-нибудь флаг (если у него его еще нет), указывающий, хранятся ли строковые данные как Ansi или Unicode, и ваши приложения должны будут искать этот флаг.,

Есть ли какой-нибудь общий способ, где я могу указать UnicodeString на массив байтов, который может быть изначально записан как байты ANSI или Unicode, и он выяснит, что это такое?

Нет. Вы должны знать фактическую кодировку байтов заранее. Если вы передаете адрес памяти System::AnsiString или же std::string, это собирается принять Ansi персонажей. Если вы передаете тот же адрес памяти System::UnicodeString или же std::wstring, вместо этого предполагается использовать символы Юникода.

Сторонние компоненты. В основном мы используем SpTBX, и он выглядит совместимым.

Как и во всех предыдущих версиях (за исключением перехода с 2006 на 2007), любые сторонние компоненты, которые у вас есть, нужно будет перекомпилировать для 2010, либо вручную (если у вас есть исходный код для них), либо с помощью их соответствующих поставщики.

Обновления проекта. Стандартный совет на форумах Codegear, похоже, заключается в том, чтобы вручную обновлять все файлы проекта при обновлении.

Да. Это все еще применяется.

Я знаю, что есть новый редактор и формат библиотеки типов (он хранит IDL, то есть текст, и генерирует TLB динамически?)

Файлы.TLB больше не используются. Новая система теперь работает с файлами.ridl (Reduced IDL). Во время компиляции.ridl создает правильную информацию TypeLibrary непосредственно в двоичных ресурсах исполняемого файла. Файлы.tlb не создаются.

Насколько хорошо это справляется с обновлением существующих проектов COM с помощью TLB? У нас есть код Delphi и TLB, которые встроены в приложение C++.

Я не помню, может ли CB2010 (или CB2009, в этом отношении) напрямую использовать уже существующие файлы.tlb. Я не думаю, что они могут. Однако вы можете запустить файл.tlb через tlibimp.exe, и он экспортирует файл.ridl. Или вы можете скопировать текст IDL из редактора TLB в предыдущей версии и вручную вставить его в новый файл.ridl. В любом случае, вы можете добавить этот.ridlle в ваш проект CB2010.

2007 и 2010 сосуществуют. Я не уверен, что доверяю этому ответу, так как у меня были проблемы с 2006 и 2007 годами на одной машине раньше.

Вот почему я использую виртуальные машины при установке нескольких версий IDE на одной физической машине.

Источник

Вы не говорите, для чего предназначены строки данных в вашем двоичном формате кортежей: нужно ли им хранить Unicode? Когда я перешел с D2007 на D2009, я смог сохранить только некоторые части системной строки ANSI.

Если требуется сохранение Unicode, вам необходимо проверить, совместимы ли ваши существующие данные с таким форматом, как UTF-8. Если диапазон значений, хранящихся в существующих файлах данных, представляет проблему, я бы заставил ваше следующее обновление выполнить однократное преобразование любых старых файлов данных, считав старые данные AnsiString и записав их как UTF-8 в другой файл. имя файла или расширение, или путем изменения соответствующих данных заголовка файла. Я долгое время занимался версионированием файлов данных, просто для того, чтобы позволить такое изменение обработки.

Я только начинаю проект BCB2010, поэтому не могу комментировать ваши другие вопросы, но у меня наверняка были проблемы с обновлением проекта Delphi с D2007 до D2009 - хотя я смог это исправить, отредактировав файл проекта, который представляет собой просто XML.

Удачи с преобразованием;-)

Источник

Соответствует ли стоимость модернизации преимуществам?

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

Такой подход был предложен для vb6 разработчики, которые думали об обновлении до vb.net,

Источник
Другие вопросы по тегам