Вообще я приводил это как достоинства Delph.

Вот об этих http://ru.wikipedia.org/wiki/Шаблон_(программирование)

Как верно написал Winstrol "Имеется в виду один event - множество обработчиков".

XML сливать тоже не просто, но Qt предполагает меньше настроек на форме, а больше кода в файлах, в делфи прямо противоположенный подход кинули компонент, и давай выставлять его свойства в object inspector-е. И как потом сливать изменения?

А это уже хамство.


Ленивые и незнанающие есть в любом языке. Проблема в другом, если у вас есть визуальная форма, как добавить на нее пару ваших эдитов, так, чтобы дизайн формы учитывал их. Есть конечно "Шаманский метод Geo", но это уже костыли.

Сорри, недоглядел.

С шаблонами все понятно, так же как и с переопределением операторов наверное (=, >, <, +, - и пр.)

А вот эта штука действительно очень хороша.

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

А про VCL, повторюсь - если разобраться - все просто и понятно, ничего сверхъестетвенного нет.

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


Накидал компонент-соединил - это извините не разработка ПО, абсолютно никак.
сложность сопровождения - зависит от архитектора проекта, от того, насколько грамотно учтены все нюансы проекта при разработке базового ядра проекта

Причем здесь это? Я говорил о другом. Qt больше ориентированно на установку свойств через код, Delphi к выставлению свойств через object inspector. Например. Несколько человек разрабатывают программу (к примеру файловый менеджер), каждый отвечает за свою часть функциональности, скажем один за дерево директорий, другой за список файлов. Оба изменили код в своих модулях, и поменяли какие-то свойства у соответствующих компонент на главной форме. Оба разработчика прислали свои версии программ для слияния. Вот тут и начинаются сложности, как слить изменения свойств в 2-х dfm файлах. Понятно, что свойства можно менять в коде, но тогда теряеться смысл дельфийского визуального программирования.
 
Да вроде у меня проблем с пониманием VCL не возникало. Я где-то говорил что мне VCL не понятна?

Разговор про написание приложения, в котором есть визуально спроектированная форма. Поведение одного или нескольких контролов должно немного отличаться от стандартного. Можно поступить 3-мя путями:

• Создать новые компоненты. Но если изменения не универсальны(нужны только для этого проекта), то вроде как глупо иметь кучу установленных компонент каждый для своего проекта. А что делать если есть 2 версии проекта, стабильная и разрабатываемая? Нельзя иметь установленными 2 версии одного компонента.
• Можно написать свой класс, но как отобразить его на форме в design time-е? Если создавать объект в рантайме, то вид формы в дизайнере Delphi не соответствует реальному виду работающего приложения.
• Учитывая эти проблемы, часто люди предпочитают небольшие изменения в поведении компонент делать через обработчики событий.

Причем третий подход даже считается нормой и описывается в большинстве статей. Вот например:
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=168
http://www.citforum.ru/programming/delphi/nogrid/

Я имел в виду прототипирование:

Впрочем не все с этим согласны:)


С этим я не спорю. Имелось в виду "при прочих разных". В целом ситуация как везде, для маленьких работ удобнее визуальный подход, для больших - невизуальный. Скажем переименовать один файл проще в файловом менеджере, F2 и все дела, но если надо переименовать 1000 файлов то проще набить команду в консоли. Delphi более визуально ориентированная среда чем C и Qt в частности. Все это мое скромное, но глубокое ИМХО:)

гхм-гхм. отвечу не по существу - в паскале тоже приходится подставлять всякие крышечки (^) и собачки (@) в разных случаях. Оба языка программирования одного порядка, достаточно низкоуровневые, поэтому при их использовании нужно иметь представление о работе железа и представлении данных в памяти.

Большущий +1

C++ (Qt)
for (i = 0 ; i < n ; i++ )
  if ( !a[i] ) {
    s[i] += m*i;
    ...
  }
 

Pascal
for i := 0 to n-1 do
   if not a[i] then
   begin
     s[i] := s[i] + m*i;
     ...
   end;
 

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

ПС пример очень маленький поэтому не очень чувствуется, но в целом надеюсь идея понятна.
ППС кстати от вопроса что было в дельфи 15 лет вы так и уклоняетесь или я пропустил этот момент ?

Вообще здесь уже пошла война Pascal vs C++ 

Если взять именно VCL против Qt - именно графическую часть - виджеты, построение интерфейса и т.д. Я переходил с Делфи и боялся что действительно не будет множества удобных компонент и т.д. Но большинство проблемных вещей в Делфи в Qt -шных виджетах решены из коробки - например:

1) Установка фонового изображения (в Qt 1 строчка в стайл-шите), кроме того стайл-шиты еще много где приходятся кстати - для меня они решают массу проблем к кот. в делфи вообще непонятно как подступиться. Например есть изображение прибора (возьмем клавиатуру телефона)- ui форма - и на ней фон - вычещенное фото этого прибора(собственно клавиатура с кнопками) - сверху кнопочки (QPushButton соответственно над каждой нарисованной в фото). Кнопки можно сделать прозрачными (чтобы не рисовать для каждой собственную подложку) - опять же через стили, но тогда неудобно их размещать (предположим что никакие лейауты не подходят так как в реальном приборе они расположены несимметрично а нам надо его повторить) - но так как они прозрачные границ то невидно... Ничего опять же в стилях ставим красные границы нужной ширины (эту строчку стиля оставляем только для себя на этапе расставления кнопок) - все расставляем в дизайнере, потом убираем строчку стиля ответственную за границы кнопочек - и ВСЕ ОК. Как такое сделать на делфи? Это реальная задача с кот. я столкнулся - только на приборе было не 10 кнопок а побольше раза в 3.

2) док-подобное главное окно - если кто заикнется что оно глючит - то в делфи MDI окошки тоже не идеально работают - например при переключении по дочерним окнам - каждое окно сворачивается, потом другое разворачивается на всю внутр. область - на небыстрых компьютерах это оч. раздражает. Кроме того есть масса глюков при попытке сохранить состояние таких окон(если программа запоминает последние открытые окошки) - помню как боролся с тем что внутреннее окно ни в какую не хотело занимать все область родительского.. может уже пофиксили все это?

3) QLabel поддерживающий не только просто текст а html - в частности для вывода подстрочного, надстрочного шрифта, смены цвета части слова - оч. удобный компонент по сравнению с TLabel (или как он там наз-ся)

3) QDesktopWidget позволяющий создавать окошки сразу на нужных мониторах,

4) TableView и TreeView - может далеки до платных дополнительных аналогов из Делфи, но весьма самодастаточны и готовы к применению в проектах с БД (по аналогии стандартный грид в Делфи вообще никуда не годится) - в ячейки этих табличек легко встраиваются самописные делегаты (в делфи по мойму со стандартной таблицей такого не сделать, и дай бог если сделать с нестандартной )

5) Кроме того написание визуальных виджетов для Qt гораздо проще и удобнее чем в делфи. К примеру мне требовалось создать виджет манометр-вольтметр-любой цифровой прибор. Где будут настраиваться засечки, шаг вывода значений и др. Я написал такой на Делфи, затем столкнулся с Qt и решил попробовать сделать то же самое там. К своему удивлению я обнаружил что имею бесплатный анти-алиасинг(кот. еще и аппаратный на большинстве карт - если я не путаюсь уже), и массу возможностей трансформаций координат отрисовки, поворотов, scale - вообщем мне QPainter показался подарком - не надо даже было рассчитывать координаты позиций стрелок достаточно вызвать метод rotate на нужный угол. Этот компонент после перевода стал в исходнике раза в 2 меньше. В результате появилось желание его улучшить и это опять же не вызвало проблем. Имеется правда маленький недостаток - так и не смог засунуть в дизайнер вложенные поля для своих классов. Чтобы они там разворачивались по нажатию "+". Это конечно оч. удобно и в Делфи работало.

6) При работе с дизайнером есть как минимум один оч. большой + у Qt дизайнера - при заполнении TabOrdera - элементы подсвечиваются и достаточно по ним щелкнуть - что может быть проще и удобнее. Может сейчас это и в Делфи есть, но когда я там работал не было и люди кот-м приходилось делать формы с большим количеством элементов - меня поймут - выделять каждый элемент и выставлять у него поле (то бишь каждый раз дергаться в инспектор объектов)это очень неудобно - того и гляди пропустишь элемент(какую-нибудь махонькую кнопочку) - и начинай ВСЕ с начала! А для пользователя забивающего накладные с кучей полей это очень удобно!

7) Тут велись споры на счет справки - кто-то сказал что в Делфи она лучше - я не согласен. В Qt Assistent я всегда нахожу то что хочу. Если не нашел чего-то значит там этого нет. В Делфи было так - в справке ЕСТЬ ВСЕ - но попробуй это найди. Скажем как найти там правила форматирования при переводе даты из Датного формата (не помню как класс там называется) в строку (те что DD.MM.YYYY) - Я как то это нашел. А потом опять понадобилось - так и не нашел... И это не единственный случай. К примеру найдется ли там опимание того как наследовать DFM формы? Ведь оно там есть? Моежт сейчас ситуация улучшилась и я не прав...

привел примеры все из своей практики