2009-12-02 1 views
3

Я пытаюсь перенести свои собственные проекты на delphi 2010. Но это кажется очень сложным.Является ли обновление D2010 действительно значимым

  1. Я использую TntControls для старых проектов. Если я удалю эту библиотеку, некоторые функции выполнения должны быть повторно реализованы мной. Например: конвертируйте UnicodeString в указанную кодовую страницу.
  2. «РазмерОф», «Длина», FillChar() все еще путают меня. Компилятор выдает предупреждение, если параметр SizeOf() должен быть заменен на Length(). Но я не нашел для меня никаких идиотских учебников.
  3. Путательное предупреждение при попытке передать AnsiString в UnicodeString. Этот разговор не приведет к потере данных, не так ли?
  4. Многие коды (zip, string utils и т. Д.) Должны быть повторно протестированы.

Слишком много головных болей ... Может ли кто-нибудь поделиться опытом по переносу существующего проекта с очень старого delphi на delphi 2010?

ответ

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

  2. РазмерOf, Length и FillChar - это очень простые концепции, которые вы, как профессиональный разработчик программного обеспечения, должны себя понять. Будьте осведомлены о том, имеете ли вы дело с символьными данными или несимвольными данными, а при работе с последними не используйте характерные типы. У вас TBytes; используй это. Не используйте строки в качестве байтовых буферов. Когда вы хотите узнать, сколько у вас байтов, используйте SizeOf; когда вы хотите узнать, сколько у вас «вещей», используйте «Длина». Как правило, избегайте FillChar; вы, вероятно, не нуждаетесь в нем столько, сколько используете его сегодня. Так как «char», что все заполнено, почти всегда равно нулю, вы можете вместо этого использовать ZeroMemory. Он имеет меньше параметров и так же быстро, как FillChar, тем более что Delphi поддерживает функцию inlining.

  3. Компилятор предупреждает вас при преобразовании из AnsiString в UnicodeString, поскольку это не просто назначение строк, а скорее преобразование, гарантированное выделение большего количества памяти и копирование всего одного символа за раз. Это предупреждение о производительности, а не предупреждение о потере данных. Конверсии в обратном направлении - как (даже при присвоении Utf8String, который технически никогда не потеряет данные из UnicodeString, если он заполнен только действительными символами Unicode). Лучший способ избежать предупреждения - не использовать AnsiString в первую очередь. Используйте простую старую строку, за исключением кода, который действительно должен знать, какую кодовую страницу кодировать.

  4. Я не думаю, что аргумент «повторного тестирования» очень силен. Код библиотеки особенно должен иметь модульные тесты, которые вы запускали каждый раз, когда вы перекомпилировали. Повторное тестирование - это то, что вы делаете несколько раз в день; нет особых усилий, если что-то пойдет не так.

+0

Назначение AnsiString для UnicodeString МОЖЕТ привести к потере данных! Вот почему компилятор выдает предупреждение для него. Это не предупреждение о производительности, это действительно предупреждение о данных. С другой стороны, назначение UnicodeString для UTF8String НЕ приведет к потере данных, поскольку UTF-8 представляет собой кодировку Unicode без потерь по дизайну, и для нее не сообщается предупреждение о компиляторе. –

+0

Какие символы, хранящиеся в AnsiString, не представлены в Юникоде, а на каких наборах символов они находятся? –

+0

Реми? У Роба есть смысл. Поразмыслить над тем, какие потери повышали бы с 8 бит AnsiString UP до UnicodeString, которые могли когда-либо возникнуть? Потому что единственная причина, по которой я думал, что это предупреждение, заключалась в том, чтобы заставить вас подумать: «Почему у меня есть эта AnsiString здесь, и разве я не теряю память и процессорное время со всеми этими неявными преобразованиями?» –

13
  1. преобразование строки Unicode на указанную страницу кода только с Delphi: проще, чем когда-либо. Благодаря способности класса String создавать строку требуемой кодовой страницы и конвертировать ее из одной кодовой страницы в другую.
  2. FillChar - это байты, а не символы, имя сейчас несчастливо. На самом деле это не так смущает.
  3. Это предупреждение, чтобы вы подумали, что он сделал. Работа выполнена.
  4. О да. Но повторное тестирование и повторное чтение были для меня самой большой выгодой.

Я мигрировал все мои проекты на Delphi 2009/2010 и обнаружил преимущества включают:

A. тщательное повторное чтение моего кода принесло много способов, мне нужно, чтобы очистить его (потому что это раздутая старая масса несчастных случаев и инкрементный кодовый шлам, как и большинство проектов RAD/delphi), некоторые из которых являются чисто юникодными или связанными с портами, но все это сделало продукты более эффективными для принудительных изменений.

B. чистый мир, с меньшим количеством сторонних компонентов. Снижение TNT и десяток или два сторонних компонента сделают ваш проект меньшим, более ортогональным и более легким для поддержки.

C. Нет причин для портирования, чтобы сделать это в одну сторону. Ни один из моих портов проекта фактически не «перемещен» на Delphi 2009/2010. Все они прекрасно строят в обоих мирах. Я использую тип UnicodeString во всем моем коде везде, где мне это нужно, и я делаю typedef для WideString при компиляции на Delphi 2007 или более ранних версиях.

D. Идея delphi 2010 отлично работает в Windows Vista и Windows 7, а язык - это радость для работы. Delphi 2009 и 2010 не разбиваются, что Delphi 2007 и Delphi 7 часто делают для меня.

Если вам не нужна поддержка Vista и Win7, и вы на 100% счастливы и без проблем используете TNT-компоненты, и ваше приложение не сделает вам деньги, а затем оставьте его там, где оно есть. Если это принесет вам деньги, инвестируйте свое время, и вы скоро увидите награды. Delphi 2010 и 2009 года являются лучшими версиями delphi, и единственной основной головной болью остается то, что документация оставалась ниже качества Delphi 7 с тех пор, как они перешли с файлов справки формата WinHelp.