Qt vs VCL

[lit-uriy]

>>Я говорил конкретно про вхождение,
Вообщше термин "Вхождение" для меня не понятен, но из описания правильнее сказать "завлечь"
В своё время я польстился такой простотой, однако понимания у меня небыло. Практика сборки (не с первого раза) Qt дала мне существенный багаж знаний.

Я даже не имел, до недавнго времени, представления о том как правильно делать incude, в С++. И что линкер нужно рассматривать отдельно.

Если говорить о новичке в програмировании, то нужно человека увлечь - согласен. Однако, сейчас, я склонен пологать, что системы типа Борланд Делфи/Билдер, в случае если мы хотим научить человека програмировать, В отсутствии опытного наставника - зло (запросто уведёт в сторону от понимания того, как "это" работает).

Такое же отношение к тому, что сейчас делают троли, в виде Creator'а. Не удобен как IDE (тотже Борланд), крив не зависимо от достоинств.

[Sokoloff]

• Красивое решение для property. IMHO более элегантно чем гетеры/сеттеры.
• Неплохой редактор, не без недостатков но неплох.
• Очень хорошая документация.

проперти - могут использовать те же геттеры и сеттеры
редактор... вот напр. 2007 редактор БОЛЕЕ чем достаточен, есть все, абсолютно все что необходимо для удобной и быстрой разработки
а вот доки после 2005 стали хромать, причем сильно, к 2009 их вроде привели в более-менее порядок, но все равно стречаютсяеще такие вот экземпляры

Property XXX

Description: this is the property XXX of YYY class.

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

О каких шаблонах идет речь???

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

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

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

про dfm - попробуйте слить юи в QT

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

в VCL надо разобраться, прежде чем писать о том, что не смог написать

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

да, свои компоненты должны регистрироваться, промоутеров конечно нет,
а про людей, которые обвешивают обработчиками каждый едит, вместо того чтобы написать свой (ИМХО лень, либо незнание), так, например для последнего проекта наша команда разработала кучу компонент (требовалась мультиязычность без привязки к ресурсным файлам), при этом и код красивый, и нет кучи обработчиков одинаковых везде, да, и хелперы к классам еще никто не отменял

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

[Sokoloff]

Под вхождением я имел в виду первые шаги человека в программировании.
Да, согласен, Delphi слишком скрывает детали, но и требовать от человека написавшего первые 5 строк кода в своей жизни, быстренько изучить опции компилятора и синтаксис make, это пребор.
Оптимум где то посередине.

В целом Delphi проще в начале. Как в начале изучения программированию. Так и в начале проекта, накидал компонент соединил - получил почти рабочую программу. Но с ростом проекта, достоинства дельфи превращаются в недостатки, сложность сопровождения, сложность расширения и/или изменения стандартных компонент(IMHO в смысле расширяемости классы в Qt продуманы гораздо лучше).

[Smilius]

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

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

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

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

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

XML сливать тоже не просто, но Qt предполагает меньше настроек на форме

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

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

как добавить на нее пару ваших эдитов, так, чтобы дизайн формы учитывал их.

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

В целом Delphi проще в начале. Как в начале изучения программированию. Так и в начале проекта, накидал компонент соединил - получил почти рабочую программу. Но с ростом проекта, достоинства дельфи превращаются в недостатки, сложность сопровождения, сложность расширения и/или изменения стандартных компонент(IMHO в смысле расширяемости классы в Qt продуманы гораздо лучше).

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

[SABROG]

А вообще приятно, что уже начинают холивары. Я бы сказал, что год-два назад такого ажиотажа не было. Определенно библиотека набирает обороты. Народ начинает сравнивать, примерять. Возможно покупка trolltech нокией благотворно отразилась на разработке.

Кстати за время общения с Borland Builder C++ (Delphi) я неоднократно натыкался на стену при попытках скомпилить opensource библиотеки компилятором bcc. Вообще сама по себе среда сложная для первого знакомства. Может быть даже QtCreator сейчас выигрывает в этом плане, чем проще среда, тем меньше свободы действий, а следовательно меньше путаницы.

Вообще Qt для меня интересная игрушка, конструктор с которым я играюсь, а не просто средство для клепания программ. Я всегда был душой с *nix системами и хотел создавать кроссплатформенные приложения. И мне сейчас достаточно фиолетово будет ли та же программа работать быстрее на MSVC или Delphi. Мне достаточно, что она будет просто работать не только под виндой.

[Sokoloff]

XML сливать тоже не просто, но Qt предполагает меньше настроек на форме

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

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

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

Да вроде у меня проблем с пониманием VCL не возникало. Я где-то говорил что мне VCL не понятна?

как добавить на нее пару ваших эдитов, так, чтобы дизайн формы учитывал их.

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

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

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

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

Накидал компонент-соединил - это извините не разработка ПО, абсолютно никак.

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

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

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

К сожалению, мы продаем именно формочки с кнопочками. и если студент не знает, что там под ними, но они собаки работают, мне как его боссу СОВЕРШЕННО ПОФИГ это.

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

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

[shadone]

Насчёт строк, в Билдер/Делфи мение очевидны различные операции со строками (возможно из-за документации), в Qt удобнее работать со строками.

Пока работаешь с QString, все ok, но если есть dll, то нужны си-шные строки, а тут или используем QString и теряем в скорости, или используем массивы char-ов, и получем все "прелести" этого. В делфи строка сделана красиво, она одновременно и дельфийская и null-terminated, проигрыша в скорости нет абсолютно.

очень надеюсь что весь тред это шутка - вы ведь сравниваете зачастую совершенно разные вещи - как например в цитате выше - QString это строка в unicode (UTF-16), как в Delphi - WideString (а вы сравниваете, насколько я понимаю, со String). И если есть dll которая ожидает сишные строки то перекодировать придется в обоих случаях.

[shadone]

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

Просто может стоит больше времени уделить чтению книг, а не устраеванию холиваров?

отчего ж.
мне, например, дико видеть i++ вместо i:=i+1, а всякие += просто пугают.
считаю, это пример неэргономичного синтаксиса, искусственно запутанного

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

[denka]

Паскаль низкоуровневый? Да аж до такой степени что в системном программирование используется

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

Просто может стоит больше времени уделить чтению книг, а не устраеванию холиваров?

отчего ж.
мне, например, дико видеть i++ вместо i:=i+1, а всякие += просто пугают.
считаю, это пример неэргономичного синтаксиса, искусственно запутанного

А на счет того borinoak не асилил работу с указателями ни там ни там на лицо иначе бы он такого не писал
На счет того что вам дико, почему то многие вещи благаполучно перешли в паскаль( а точнее в его от ветвления) из С/С++
И на счет не эргономичности: меня к примеру просту бесило писать всякие begin/end, procedure/function, var... В паскале служебных слов было больше чем на С, а вот сделать на нем можно было меньше.

[UVV]

Вообще Qt для меня интересная игрушка, конструктор с которым я играюсь, а не просто средство для клепания программ. Я всегда был душой с *nix системами и хотел создавать кроссплатформенные приложения. И мне сейчас достаточно фиолетово будет ли та же программа работать быстрее на MSVC или Delphi. Мне достаточно, что она будет просто работать не только под виндой.

Большущий +1

[pastor]

мне, например, дико видеть i++ вместо i:=i+1, а всякие += просто пугают.
считаю, это пример неэргономичного синтаксиса, искусственно запутанного

А мне в паскале дико видеть ":" перед "=".    Накой сдалось ":"? Это эргономичный синтаксис? имхо разговор перетек не в то  русло...

[f-r-o-s-t]

мне, например, дико видеть i++ вместо i:=i+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 лет вы так и уклоняетесь или я пропустил этот момент ?

[spectre71]

отчего ж.
мне, например, дико видеть i++ вместо i:=i+1, а всякие += просто пугают.
считаю, это пример неэргономичного синтаксиса, искусственно запутанного

С точки зрения эргономичности  i++ или a+=b всегда выигрывает перед i=i+1 или a=a+b;
А если бы автор достаточно разбирался в C++, и знал бы что можно переопределять операции(для своих классов), то понимал бы насколько более оптимально использование  "++", "+="
MyType a;
MyType b;
...
a += b;
a = a + b; //создается временный объект (a + b)

[break]

Вообще здесь уже пошла война 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 формы? Ведь оно там есть? Моежт сейчас ситуация улучшилась и я не прав...

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

[Winstrol]

Код

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

Вот, кстати, работа с массивами  в С++ сделана так себе. Очень нехватает полноценных встроенных массивов и операций над ними, вроде передачи параметром функции, присваивания, суммирования, foreach, динамической размерности и.т.д.