Итак, Delphi 2009, также входящий в состав CodeGear RAD Studio 2009. Хочу немного поделиться ощущениями от использования и надеюсь почерпнуть чего-то нового от коллег ;)

Около пяти месяцев назад я перевел ведомые мной проекты на двух предприятиях из среды Delphi 7 (на одном) и Delphi 2005 (на другом) на Delphi 2009. По счастливому стечению обстоятельств и конечно с Божьей помощью мои ожидания совпали с действительностью: переход прошел довольно гладко и не затребовал непропорционально большого количества времени: от нескольких часов на мелкие проекты до двух-трех дней (+ неделя на утрясание возникавших с процессе работы скомпилированного на Delphi 2009 проекта проблем) на информационную системы крупного рыбодобывающего предприятия.

Основным нашумевшим нововведением Delphi 2009 стала поддержка Юникода, позволяющая вашему проекту корректно отображать символы вне зависимости от того, какие региональные настройки являются базовыми в Windows.
Конечно же поэтому большая часть времени у меня ушла на борьбу с использованием строк string (преобразованных разработчиками Delphi 2009 из типа AnsiString в тип WideString) в системных функциях, а также стандартных функциях и процедурах Delphi. Действовать приходилось больше интуитивно, поскольку материалов на эту тему в поисковиках было не так много, как сейчас. 
Например код:  Вызывает недовольство (Warning) компилятора. Проблема решается использованием функции CharInSet: 
В ходе этой работы к одному важному для себя выводу я пришел: там, где это возможно, лучше и проще переходить на на аналоги функций, использующих WideString, а не просто менять в своем коде объявление переменных или параметров со string на AnsiString. 
В части, касающейся строк, будующее в Delphi за типами string(WideString), Char(WideChar) и PChar(PWideChar).  К счастью уже есть полноценные статьи на эту тему "Delphi в мире Юникода", написанные, на сколько я понял, одним из разработчиков Delphi 2009:
часть №1;
часть №2;
часть №3.

Были также проблемы с автоматическим переключеним раскладки клавиатуры, при переключении между контролами формы, решение которой уже к счастью найдено: строка  в модуле проекта решает проблему.

Таже неприятная ситуация была с искажением кодировки заголовков таблиц в отчетах FastReport v.4, содержащих TfrxDBCrossView.

Но все эти проблемы оказались вполне решаемыми. Для меня было главным, что в результате я получил возможность работать в среде, более комфортной, чем Delphi 7 и в разы более надежной, чем Delphi 2005. Согласитесь, довольно приятно неделями отлаживать в среде крупные проекты и при этом:
1. Практически не получать сообщения об ошибке Delphi.
2. Не перезапускать Delphi из-за сбоев и зависаний.
3. Не терять части не сохраненного кода после зависания или непредвиденного закрытия среды.
Delphi 2009 - надежная среда, не лишенная недоработок, но надежная, и это мне нравиться!

Но до сегодняшнего дня я постоянно ловил себя на мысли, что если меня спросят: а что из новых полезных возможностей Delphi 2009, не доступных в предыдущих версиях ты можешь назвать, мне бы практически нечего было ответить. Сегодня у меня появилось время и я полез в yandex. Нашел я пару заинтересовавших меня статей: существенные нововведения: анонимные методы и Generics (шаблоны) и новые компоненты в Delphi.
Попробовав Generics TList (эксперименты проводил в Delphi 2010), описанный в модуле Generics.Collections я ощутил удобства хранения списков различного типа (простых типов и записей), когда нет необходимости самостоятельно разрабатывать системы порционного выделения памяти и(или) работать с указателями на объект.

Областей применения анонимных методов для себя я не нашел.
Возможность передавать параметр процедуре Exit, который будет записан как Result функции думаю оценят многие.

Из компонентов я успел оценить только палитру Ribbon Controls. Те, кому пришлись по душе изменения, затронувшие Microsoft Office 2007 также смогут оценить эти компоненты по достоинству.

У меня пока все. Если у кого-то есть ссылки на материалы затрагивающие вопросы применения новшеств Delphi 2009 и Delphi 2010, будет интересно посмотреть. Делитесь своими мнениями касательно Delphi 2009.

С уважением,
Федор.

Дженериковый TList неюзабилен до версии 2010. Если вплотную работал - должен был заметить.
Пример я давал тут: http://forum.vingrad.ru/index.php?showtopi...t&p=1957440

  А если нужно будет букву "Б" проверить на множество то как? В юникоде она 2х байтовая.

Наверное, так:

CodeMonkey, за линейное время и дурак может. Той же функцией pos или еще 10ю способами, "Key in [#13, #8]" дает константное время, это уже совсем другая производительность  . Ну хотя бы за логарифмическое время, хотя логарифмическое время потребует длительной вставки.

Если честно, я с трудом представляю себе ситуацию, где это реально играет роль.

  Еще как играет, если множество достаточно большое, а цикл в 3 вложения, там еще поиск и удаление фрагментов по найденным позициям или замена. А теперь представь что обрабатывать таких текстовых файлов нужно штук 15 за раз. Или же эту операцию нужно сделать при переключении окон, т.е. мгновенно. Или же речь идет о специализации, обмене данными между приложениями в текстовом виде.
  Удобная работа со строками это одна из главных фич делфи, так необходимая в связке с БД или сетью (HTML/XML). В сочетании с быстрым менеджером куч, быстрыми строковыми алгоритмами, автоматические динамические строки весьма удобное средство.

Имхо пора прикручивать поддержку "широких" множеств

Циферки будут? 

  Например 100-200 это уже немало. Операция сравнения или поиска как раз обычно глубже всего в цикле, а тут еще лишний цикл вырисовывается, счетчик цикла уже не в регистре, а стеке, и без jmp/cmp уже не обойтись, ветвление начинается, учитывая что работа с БД и сетями неразрывно связана со строками. Ты же пойми, это не однократная операция, а самая что ни на есть массовая, может даже более массовая чем выделение памяти. Это тот тип алгоритмов, которые разработчики VCL оптимизируют на асме, как функцию pos или же оператор сравнения строк или как копирование. В то время как космические корабли бороздят просторы большого театра... В то время как цепочечные операции стараются оптимизировать при помощи SSE, при копировании памяти задействовать DMA было бы расточительным заменить константное время даже на логарифмическое, но никак не на линейное.

100-200 чего?

Alexeis ты как-то упускаешь из виду, что C in Set - тоже не бесплатная операция. Она включает в себя оперирование битами. Это медленнее, чем манипулирование байтами. Чтобы найти символ в строке - на ассемблере это одна команда (один из вариантов REP). Но чтобы найти символ во множестве (а особенно в word-множестве, если бы оно было) - это задача несколько сложнее. Надо выделить нужный байт и проверить в нём нужный бит (с использованием логических операций). Понятно, что время выполнения такой операции константа, в то время как скан строки зависит от размера этой строки. Но проблема в том, что накладные расходы на манипуляцию битами могут съедать весь выигрыш.

Например, вот такой простой тест:



Для пол-миллиардов проходов и множестве из 4-х десятков Unicode-символов тест эквивалентные результаты для StrScan и in (около 1 с. на моей машине для каждого способа). И это с учётом того, что множество фильтрует только ANSI-символы.

Константного времени можно добиться только конвертацией Unicode в ASCII (Char в AnsiChar). Функция TEncoding.Convert должна с этим справляться. Свойство Default класса TEncoding ссылается на активную кодовую ANSI-страницу.


Почитав комментарии касающиеся Generics на этом форуме, я даже пробовать их не стал на 2009, как и писал выше эксперименты с Generics я проводил в Delphi 2010.

CodeMonkey, хех товарищ, тут допущено несколько грубых ошибок.
1) в 39й строке
2) Концептуальное. Использование массивов не умещающихся в кэше проца. Работа с такими массивами раз в 20 медленнее чем с нормальными. Короче время жестко загрублено.

см мой код


Результаты 3 тика и 72 тика, что в 24 раза выше! 
Причем результат для первого варианта медленно растет, так что скорее всего реальное значение куда меньше (еще имеется загрубление), а второй код четко линейно растет с числом итераций.

Вывод! Белое не может быть черным по определению. Битовые операции весьма быстры, кроме того проверка множества состоит в том чтобы проверить всего 1 битик, т.е. бит сдвигаем вправо и делаем операцию and и сравнение. Это очень быстрые операции для процессора к тому же однократные. 

Тьфу, опетачался 


Это следует из:

Есть мнение, что набор типичных текстовых файлов не умещается в кэше процессора. Алгоритм не делает ничего, кроме проверки вхождения символа во множество. Тем не менее, выбор способа проверки слабо влияет на время работы. По-моему, это и есть практическая оценка, нет?

Зато смысла делать тест для множества из 127 символов я не понимаю. Чем (Ch >= 'А') and (Ch <= 'Я') не устраивает? Это ещё быстрее, чем in.

Я вовсе не утверждаю, что белое - это чёрное. Я говорю, что в большинстве случаев тут нет никакой разницы. ИМХО, конечно. 


Тогда весь смысл Unicode пропадает. Это значит, что программа не будет работать на машинах, где стоят "не ваши" настройки. Получаем Unicode программу, которая работает в условиях для ANSI программы 

  127 символов это строка для анализа. Набор символов старый. Обычно размер типичной строки не превышает 200 символов.


  Ну почему же, представь ты работаешь с БД или сетью, получил данные обработал, записал. На момент обработки вероятно пришлось залочить текущую строку в базе или даже группу строк, после записи строки разблокируются и к ним получают доступ другие клиенты. Ситуация когда ты монопольно владеешь ресурсом не редка, в этом случае задача программиста свести время блокировки к минимуму. Нельзя же считать что твоя задача это пуп земли. Возможно твоему процессу приходиться работать в условиях когда процессор занят на 99% гораздо более важной задачей. Вот например мой рабочий проект обрабатывает строковые команды извлекает строку команды, параметры и отправлял данные по USB, процессор в это время загружен отрисовкой 3D модели, помимо моего потока запущено еще как минимум 5 потоков и все просят процессор.

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

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