Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Delphi: Общие вопросы > Что нового в Delphi 2009


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

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

Основным нашумевшим нововведением Delphi 2009 стала поддержка Юникода, позволяющая вашему проекту корректно отображать символы вне зависимости от того, какие региональные настройки являются базовыми в Windows.
Конечно же поэтому большая часть времени у меня ушла на борьбу с использованием строк string (преобразованных разработчиками Delphi 2009 из типа AnsiString в тип WideString) в системных функциях, а также стандартных функциях и процедурах Delphi. Действовать приходилось больше интуитивно, поскольку материалов на эту тему в поисковиках было не так много, как сейчас. 
Например код: 
Код

  if Key in [#13, #8] then
    DoSomething;
 Вызывает недовольство (Warning) компилятора. Проблема решается использованием функции CharInSet: 
Код

  if CharInSet(Key, [#13, #8]) then

В ходе этой работы к одному важному для себя выводу я пришел: там, где это возможно, лучше и проще переходить на на аналоги функций, использующих WideString, а не просто менять в своем коде объявление переменных или параметров со string на AnsiString. 
В части, касающейся строк, будующее в Delphi за типами string(WideString), Char(WideChar) и PChar(PWideChar).  К счастью уже есть полноценные статьи на эту тему "Delphi в мире Юникода", написанные, на сколько я понял, одним из разработчиков Delphi 2009:
http://edn.embarcadero.com/article/38446;
http://edn.embarcadero.com/ru/article/38582;
http://edn.embarcadero.com/article/38703.

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

PInteger(@Screen.DefaultKbLayout)^:=-1;
 в модуле проекта решает проблему.

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

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

Но до сегодняшнего дня я постоянно ловил себя на мысли, что если меня спросят: а что из новых полезных возможностей Delphi 2009, не доступных в предыдущих версиях ты можешь назвать, мне бы практически нечего было ответить. Сегодня у меня появилось время и я полез в yandex. Нашел я пару заинтересовавших меня статей: http://www.xakep.ru/post/44864/default.asp и http://www.delphilab.ru/content/view/257/1/.
Попробовав Generics TList (эксперименты проводил в Delphi 2010), описанный в модуле Generics.Collections я ощутил удобства хранения списков различного типа (простых типов и записей), когда нет необходимости самостоятельно разрабатывать системы порционного выделения памяти и(или) работать с указателями на объект.

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

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

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

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

Автор: bems 8.9.2009, 14:27
Дженериковый TList неюзабилен до версии 2010. Если вплотную работал - должен был заметить.
Пример я давал тут: http://forum.vingrad.ru/index.php?showtopic=271420&view=findpost&p=1957440

Автор: Alexeis 8.9.2009, 15:01
Код

CharInSet(Key, [#13, #8])

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

Автор: CodeMonkey 8.9.2009, 16:27
Цитата(Alexeis @  8.9.2009,  15:01 Найти цитируемый пост)
 А если нужно будет букву "Б" проверить на множество то как?

Наверное, так:
Код
if LastDelimiter(#13#8'Б', S) > 0 then

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

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

Автор: Alexeis 8.9.2009, 19:30
Цитата(CodeMonkey @  8.9.2009,  17:03 Найти цитируемый пост)
Если честно, я с трудом представляю себе ситуацию, где это реально играет роль. 

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

Автор: bems 8.9.2009, 19:36
Имхо пора прикручивать поддержку "широких" множеств

Автор: CodeMonkey 8.9.2009, 19:49
Цитата(Alexeis @  8.9.2009,  19:30 Найти цитируемый пост)
Еще как играет, если множество достаточно большое

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

Автор: Alexeis 8.9.2009, 20:16
Цитата(CodeMonkey @  8.9.2009,  18:49 Найти цитируемый пост)
Циферки будут?

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

Автор: CodeMonkey 8.9.2009, 23:01
Цитата(Alexeis @  8.9.2009,  20:16 Найти цитируемый пост)
100-200 это уже немало

100-200 чего?

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

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

Код
procedure TForm1.FormCreate(Sender: TObject);

  function StrScan(const Str: PChar; Chr: Char): PChar; inline;
  begin
    Result := Str;
    while Result^ <> Chr do
    begin
      if Result^ = #0 then
      begin
        Result := nil;
        Exit;
      end;
      Inc(Result);
    end;
  end;

const
  CheckCount = 500000000;
var
  X: Integer;
  T: Cardinal;
  Arr: array of Char;
  S: set of Char;
  B: String;
  C: Boolean;
  Ch: Char;
begin
  SetPriorityClass(GetCurrentProcess, REALTIME_PRIORITY_CLASS);
  SetLength(Arr, CheckCount);
  Randomize;
  for X := 0 to CheckCount - 1 do
    Arr[X] := Char(Random(65536));

  // Prepare
  S := ['0'..'9', 'А'..'Я', 'g'];
  B := '';
  for Ch := '0' to '9' do
    B := B + Ch;
  B := 'g';
  for Ch := 'А' to 'Я' do
    B := B + Ch;

  // Warmup
  C := False;
  for X := 0 to CheckCount - 1 do
    C := C or (Arr[X] in S);
  Tag := Ord(C);

  C := False;
  T := GetTickCount;
  for X := 0 to CheckCount - 1 do
    C := C or (Arr[X] in S);
  T := GetTickCount - T;
  Caption := Caption + ' ' + IntToStr(T);
  Tag := Ord(C);

  // Warmup
  C := False;
  for X := 0 to CheckCount - 1 do
    C := C or (StrScan(PChar(B), Arr[X]) <> nil);
  Tag := Ord(C);

  C := False;
  T := GetTickCount;
  for X := 0 to CheckCount - 1 do
    C := C or (StrScan(PChar(B), Arr[X]) <> nil);
  T := GetTickCount - T;
  Caption := Caption + ' ' + IntToStr(T);
  Tag := Ord(C);
end;


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

Автор: Fedia 9.9.2009, 00:48
Цитата(Alexeis @  8.9.2009,  15:01 Найти цитируемый пост)
А если нужно будет букву "Б" проверить на множество то как? В юникоде она 2х байтовая. 

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

var
  ArB: TBytes;
begin
  ArB := TEncoding.Convert(TEncoding.Unicode, TEncoding.Default,
    TEncoding.Unicode.GetBytes(Key));

  if CharInSet(AnsiChar(ArB[0]), [#13, #8, 'б']) then
    ShowMessage('Есть во множестве');
 Свойство Default класса TEncoding ссылается на активную кодовую ANSI-страницу.

Цитата(bems @  8.9.2009,  14:27 Найти цитируемый пост)
Дженериковый TList неюзабилен до версии 2010. Если вплотную работал - должен был заметить.

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

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

см мой код
Код

procedure TForm1.FormCreate(Sender: TObject);

function StrScan(const Str: PChar; Chr: Char): PChar; inline;
  begin
    Result := Str;
    while Result^ <> Chr do
    begin
      if Result^ = #0 then
      begin
        Result := nil;
        Exit;
      end;
      Inc(Result);
    end;
  end;

  {J+}
  const s1 : array [0..127] of char = 'aАrgaукреке№ккнer7&gijreруtyк54o/iiaqkerjgeriгдщjger54д445ijgeir@tt<>fddвукУУПке-=!ё`jhцуцщпр/*-,004апЛrrehdsеНЕ$&dserhпаОЛку';
  {J-}

var
  S: set of Char;
  B: String;
  C  : Boolean;
  Ch : Char;

  PerfCount1, PerfCount2 : TLargeInteger;
  t1, t2, t3, i : Integer;

begin
  SetPriorityClass(GetCurrentProcess, REALTIME_PRIORITY_CLASS);

  // Prepare
  S := ['0'..'9', 'А'..'Я', 'g'];
  B := '';
  for Ch := '0' to '9' do
    B := B + Ch;

  B := B + 'g';
  
  for Ch := 'А' to 'Я' do
    B := B + Ch;
  // Warmup
  C := False;

  Ch := 'z';

  QueryPerformanceCounter(PerfCount1);
  for i := 0 to 127 do
    if (s1[i] in S) then Ch := s1[i];
  QueryPerformanceCounter(PerfCount2);
  t1 := PerfCount2 - PerfCount1;


  QueryPerformanceCounter(PerfCount1);
  for i := 0 to 127 do
    if (StrScan(PChar(B), s1[i]) <> nil) then Ch := s1[i];
  QueryPerformanceCounter(PerfCount2);
  t2 := PerfCount2 - PerfCount1;

  Ch := 'z';

  QueryPerformanceCounter(PerfCount1);
  QueryPerformanceCounter(PerfCount2);
  t3 := PerfCount2 - PerfCount1;
  t1 := t1 - t3;
  t2 := t2 - t3;

  ShowMessage(Ch + ' ' + IntToStr(t1) + ' ' + IntToStr(t2));
end;


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

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

Автор: CodeMonkey 9.9.2009, 13:39
Цитата(Alexeis @  9.9.2009,  10:05 Найти цитируемый пост)
1) в 39й строке

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

Цитата(Alexeis @  9.9.2009,  10:05 Найти цитируемый пост)
Использование массивов не умещающихся в кэше проца.

Это следует из:
Цитата(Alexeis @  8.9.2009,  19:30 Найти цитируемый пост)
А теперь представь что обрабатывать таких текстовых файлов нужно штук 15 за раз.

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

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

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

Цитата(Fedia @  9.9.2009,  00:48 Найти цитируемый пост)
Свойство Default класса TEncoding ссылается на активную кодовую ANSI-страницу.

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

Автор: Alexeis 9.9.2009, 14:34
Цитата(CodeMonkey @  9.9.2009,  12:39 Найти цитируемый пост)
Зато смысла делать тест для множества из 127 символов я не понимаю. Чем (Ch >= 'А') and (Ch <= 'Я') не устраивает? Это ещё быстрее, чем in.

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

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

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

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

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

Автор: Fedia 9.9.2009, 22:22
Цитата(CodeMonkey @  9.9.2009,  13:39 Найти цитируемый пост)
Тогда весь смысл Unicode пропадает. Это значит, что программа не будет работать на машинах, где стоят "не ваши" настройки. Получаем Unicode программу, которая работает в условиях для ANSI программы smile 

Согласен smile
Что здесь можно предложить? Наверное переводить не в дефолтную кодовую страницу, а в ту, которая нужна разработчику.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)