Как выбрать путь миграции с Delphi 2007

Question

Я работаю с командой над большим приложением с Delphi 2007. Оно использует более крупную унаследованную среду для доступа к данным. И приложение, и фреймворк используют String в качестве типа данных для строк. Я начал изменять код в среде для поддержки строк Delphi 2009, см. Мои предыдущие вопросы по этому поводу.

Сейчас я вижу 2 варианта:

Alt 1 - Продолжать использовать строку, как и раньше. Это, вероятно, самое чистое решение, так как фреймворк будет поддерживать Unicode. Но код в фреймворке должен быть сильно изменен, чтобы это работало. Это требует глубокого понимания внутренних алгоритмов в фреймворке. Это также больше шансов представить новые ошибки.

Alt 2 - Заменить String на AnsiString, а Char на AnsiChar. Вероятно, это гораздо более простое решение, а также то, как я начинаю изменять код (но затем я начинаю думать и задавать этот вопрос ...). Отрицательной стороной этого является отсутствие поддержки Unicode. Поддержка Unicode не обязательна, поскольку работала раньше, но приятно иметь ее. Это также может быть полезно в будущем. Другая проблема заключается в том, что приложение должно отправлять переменные Ansistring в качестве параметров в методах для структуры вместо String, как и раньше. Есть тысячи звонков для изменения ...

Так что я не знаю сейчас. Оба варианта требуют много работы, но Alt 1, вероятно, более рискованно и требует много времени. От этого форума мне нужны отзывы и комментарии, так как я думаю, что я не первый, у кого возникла эта проблема.

EDIT Другая проблема - след памяти. Я написал быстрый тест, который выделил массив из миллиона строк. Каждая строка была заполнена 26 символами от А до Я.

В Delphi 2007 это заняло 40.011.600 байт, а время составило 4:15 минут. В Delphi 2009 это заняло 72.015.580 байт, а время составило 4:45 минут.

Потребление памяти измерялось с помощью GetHeapStatus.TotalAllocated.

Я не думаю, что мы можем позволить, чтобы строки выделяли вдвое больше памяти.

Нет ничего необычного в том, чтобы потреблять 500 МБ памяти для каждого клиента. Я думаю, что многое из этого в виде строк. Вероятно, мы стараемся максимально использовать AnsiString.

Привет

Answer 1

Либо оставайтесь со старой версией Delphi, либо пройдите весь путь. Вам все равно придется рано и поздно.

Обратите внимание, что схема «замените все на ansistring» также не является полностью надежной, особенно если вы касаетесь потоков и ваши файловые форматы должны оставаться неизменными. Больше нет явных списков TStringlist, tstringstream и т. Д. С анистрингом.

То же самое, вероятно, относится к Datasnap, Indy и другим фреймворкам.

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

Answer 2

Год назад мы оценили переход 2007 -> 2009 и попробовали небольшой проект (200 тыс. Строк). В результате везде, где вы не используете «причудливые» вещи, такие как указатели, набор символов и т. Д., Портирование действительно не так сложно. Особенно модули GUI, которые мы портировали в течение дня или около того. Это эквивалентно opt1.

Библиотечные блоки с низкоуровневыми процедурами, доступом к измерительным системам и т. Д. Были совершенно другой историей. Здесь мы решаем перевести строку -> ansistring, char -> ansichar и т. Д. И т. Д. Портировать эти единицы очень сложно, и заказчик не будет платить за переход. Следовательно opt2 для этих единиц.

Этот смешанный метод дал нам лучшее из обоих миров, но мы будем держать некоторые большие проекты на Delphi 2007 и, возможно, только портировать, когда выйдет 64-битная версия компилятора.

Answer 3

Начните с «alt 2», затем постепенно добавляйте поддержку Unicode в вашу платформу, затем переходите к Unicode.

Обоснование: вы хотите стабильное приложение; переход на Delphi 2009+ в конечном итоге потребует от вас действительно поддержки Unicode.

Редактировать : 20100125

При выполнении «alt 2» следите за предупреждениями компилятора Delphi.
Ситуация, описанная Andreas , будет генерировать такие подсказки и предупреждения.

Я объяснил это в моей CodeRage 4 сессии о Unicode и других кодировках .
Приведенная выше ссылка указывает на страницу, где вы можете просмотреть воспроизведение этого сеанса.

Если у вас все еще есть вопросы, просто оставьте их здесь.

- Йерун

Answer 4

Это будет больше работы, но я действительно рекомендую вам перейти на строки Unicode, потому что это собственный тип строки VCL, и все ваши элементы управления будут иметь дело со строками Unicode в любом случае.Попытка конвертировать все назад и вперед вызовет у вас множество неприятностей.