Qt vs VCL

[niXman]

Прошу прощения за оффтоп...
Большинство прогеров, которые начинали на билдере писать, много лет от него уйти не могут. Потому что в этом случае придется учить ПРОГРАММИРОВАНИЕ. Да да, не быдлокодерство, а настоящее программирование, а большинство билдер-прогеров(их можно как подвид определять), это не программисты. Программист - это высокое звание, это образ мысли, образ жизни. А они, всего лиж говнокодеры. Вот тут труды(в кавычках) писаные им-подобными: http://govnokod.ru/
Тьфу...

[niXman]

Все в QT хорошо, но сам креатор существенно тормознее тех же седьмых дельфей в работе, про скорость компиляции я даже не упоминаю, тут глупо сравнивать компиляцию паскаля и с++)

И еще в QTWebkit очеень криво с флешем в линуксе работает, а мой проект как раз на это завязан и я фактически ни за что получаю от начальства) Поэтому моя любовь к QT перерастает в ненависть))

Код в студию! И фотку свою тожА. Чтоб было видно откуда руки растут!

[kuzulis]

Программа именно не интерфейсного характера, что является как известно основным приемуществом Delphi. Она многое чего использует из WinApi ( QT может обратиться к winapi? Улыбающийся  в общем работает на достаточно низком уровне

Ёпт! А что же использует QT в конечном итоге? astral.dll ? или pavelgloba.dll ?

ЗЫ:
и вообще, посмотрите наконец исходники классов QT  !

[Winstrol]

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

Я и так знаю, что нет. Как и нельзя написать функцию swap обменивающию килограммы, чтобы можно было без изменения применять ее к рублям.

Нетривиальные полезные свойства строгой типизации для сокращения повторной писанины никак не задействуются. --- это вообще ШаДевР

Именно так. Описывать типы вручную, когда это может делать машина, не очень хорошая идея.

Ну вообще то "сишный язык" был придуман и также как все в этой жизни на бумаге сначала.

Грамматика С не была придумана на бумаге. Была сначала реализация, что восстановить по ней формальную грамматику задача не из легких. Ее и нет (тот же Страуструп в приложении к 3 изданию пишет, что описанная им грамматика приблизительна). Ни грамматики в открытом доступе в инете, ни готовых парсеров. От того и наличие открытых сред для Java с completion,refactoring превосходит аналоги на C/С++ на несколько порядков.

[Smilius]

И кто-нибудь сообщит, как в Delphi дела с layout manager'ами?

Никак не обстоит. Нету там такого. Есть нечто похожее в сторонних компонентах от того же DevExpress. Но за отдельные бабки.

Манагеров нет, но есть не менее удобные вещи как Anchor's (и кстати сравнивать тоже нельзя - это другое, и этого нет в QT)

А по топику - сам пишу уже 10 лет (от делфи 3 до 2007 в наст. время), как у любого проекта есть хреновые версии, есть хорошие, есть плюсы и минусы, и писать можно быстроработающее ПО (стабильное, с удобным интерфейсом и пр.) хоть на QT хоть на Delphi (вот только в дельфях нет  НОРМАЛЬНОЙ кроссплатформенности) - все зависит от рук программиста, а хаяють любой язык и любую среду можно.

По промышленной разработке где-то здесь прочитал - фигня все то что "делфи не предназначен для этого" - опять же, все дело в руках программиста - если они кривоваты - то на любом языке и в любой даже самой хорошей среде можно такое понаписать....... на моем счету (как одного из группы разработчиков) 5 крупных проектов  в промышленной эксплуатации стабильно работающих несколько лет, при этом и юзабилити и скорость, и стабильность - все на высоком уровне, и написаны они именно на Делфи.

Про стабильность дельфей еще... аптайм 2007 (лиценз.) у меня достигает 3-4 суток (8-10 часов разработки с отладкой), больше просто не проверял

И если уже обо всем говорить - отладчик, который идет с QT ужасно тормозной (в особенности чем больше callstack - тем тормознее) по сравнению с тем же дельфийским (даже в версии 7.0) или с МС виз. студией.

Лично у меня выбор того или иного средства возникает ТОЛЬКО в начале какого либо проекта, когда происходит оценка и времени, ресурсов (в т.ч. человеческих) которые необходимо затратить на проект, оценка ТИПА проекта и пр... На мой взгляд - нужно прикладное ПО кроссплатформенное - QT, прикладное ПО быстро и под винду - Дельфя.

[Winstrol]

И кто-нибудь сообщит, как в Delphi дела с layout manager'ами?

Никак не обстоит. Нету там такого. Есть нечто похожее в сторонних компонентах от того же DevExpress. Но за отдельные бабки.

Манагеров нет, но есть не менее удобные вещи как Anchor's (и кстати сравнивать тоже нельзя - это другое, и этого нет в QT)

Пример в студию, чем удобны Anchors.

[spectre71]

Пример в студию, чем удобны Anchors.

Пример в студию, чем не удобны Anchors.

[Winstrol]

Пример в студию, чем удобны Anchors.

Пример в студию, чем не удобны Anchors.

Пример дать не могу, т.к. на Delphi лет 7 не смотрел. Хотя бы тем, свойство компонента Anchors ни разу не знает о соседних виджетах на форме. Где может текст сменится, размер, и.т.д. и.т.п.

[break]

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

Да не от языка это зависит как вы понять не можете! Такую функцию можно на любом языке написать - не представляю какой у вас опыт программирования чтобы вы так уверенно утверждалит такую глупость...

[Sokoloff]

Как и нельзя написать функцию swap обменивающию килограммы, чтобы можно было без изменения применять ее к рублям.

Насколько я понимаю человек хотел сказать что в Delphi нет шаблонов.
Внесу свои 5 копеек.
Приемущества Delphi/Pascal:

• Быстрая компиляция, действительно pascal компилиться намного быстрее чем C.
• Красивое решение для property. IMHO более элегантно чем гетеры/сеттеры.
• Неплохой редактор, не без недостатков но неплох.
• Очень хорошая документация.
• Наличие готовых комонент, типа ehLib, можно быстро сделать и показать прототип программы. Заказчик может покликать по кнопочкам, посмотреть на диалоги, примерно понять как он будет работать с программой.
• Низкий порог вхождения, все готово из коробки, никаких доп. действий для компиляции, написал-F9-получил. Я знаю людей которые обломились изучать C после того как несмогли, сходу, скомпилировать helloworld.
• Встроенные типы string и динамический массив. String еще и совместим с сишной строкой, нет накладных расходов на преобразование.

Надостатки Delphi перед Qt и C++.

• Отсутствие шаблонов.
• Отсутствие множественного наследования, правда, несколько компенсируется интерфейсами.
• Проблемы с подключением внешних dll, требуется писать pas-файлы обертки.
• Затруднительно слить два dfm файла (описние формы), при коллективной работе тяжело сливать изменения от нескольких разработчиков.
• Event может быть привязан только к одному обработчику, в большом проекте появляются разлапистые функции диспетчеры ивентов.
• Проблемы с созданием визуальных плагинов, из-за своего диспетчера памяти.
• VCL компоненты написаны коряво, расширять их функционал неудобно. Для примера, все удобные, сторонние DbGrid-ы  не унаследованны от TDBGrid.
• Нельзя бросить на форму свой компонент, его нужно устанавливать, нет аналога Qt-шного "promote component". Поэтому вместо написания своего TMyEdit, люди обвешивают событиями стандартные TEdit.

Это то, что сразу пришло в голову. Порядок следования ничего не означает.
P.S. Последнее Delphi с которым я работал - это семерка, может в новых что-то исправили, добавили.

[Winstrol]

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

Да не от языка это зависит как вы понять не можете! Такую функцию можно на любом языке написать - не представляю какой у вас опыт программирования чтобы вы так уверенно утверждалит такую глупость...

Ой, еще один теоретик, который все может написать на Паскале. И на на машине Тьюринга , ага.
Ну вперед, функцию swap очень даже практически полезную для реализации сортировки банального массива. Ну а ежели мало, то сборку сборку мусора на Паскале.

[lit-uriy]

2 Sokoloff, хороший список. Но не соглашусь с такими местами:
Приемущества Delphi/Pascal:

• Неплохой редактор, не без недостатков но неплох. - после сцинтилоподобных очень неуклюжий.
• Очень хорошая документация. - категорически не согласен, документация Qt намного удачнее.
• Низкий порог вхождения - Я расматриваю инструмен по двум параметрам:
  
  • Скорость освоения - тут спорно, что лучше IDE (Делфи, Студия, ...) или консольные инструменты компиляции (make...)
  • Время на востановление навыков - Qt явно в выигрыше
• Насчёт строк, в Билдер/Делфи мение очевидны различные операции со строками (возможно из-за документации), в Qt удобнее работать со строками.

Надостатки Delphi перед Qt и C++.

• Отсутствие множественного наследования, - ну в Qt виртуальное тоже невозможно, для наследников QObject
• В этом сравнении забыта локализация, крайне просто реализованная в Qt, в купе с концепцией компоновщиков, позволяет избежать ляпов, которые встречаются, например, при локализации того же Лазаруса (когда перевод на русский язык не помещается в виджет, т.к. его размер автоматически не подстраивается под окружающие виджеты и под внутренности)

Надостатки Qt

• Имена свойств размеров/компоновщиков, например, при визуально проектировании окна если задать виджету sizeHint = minimum, то он может увеличится, что не очевидно.

[Smilius]

Пример в студию, чем удобны Anchors.

Так сказано же - СРАВНИВАТЬ - НЕЛЬЗЯ!!! - это другое

С помощью якорей можно так же строить интерфейс, где меняются размеры и пр.

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

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

Property XXX

Description: this is the property XXX of YYY class.

Надостатки Delphi перед Qt и C++.

• Отсутствие шаблонов.
• Отсутствие множественного наследования, правда, несколько компенсируется интерфейсами.
• Проблемы с подключением внешних dll, требуется писать pas-файлы обертки.
• Затруднительно слить два dfm файла (описние формы), при коллективной работе тяжело сливать изменения от нескольких разработчиков.
• Event может быть привязан только к одному обработчику, в большом проекте появляются разлапистые функции диспетчеры ивентов.
• Проблемы с созданием визуальных плагинов, из-за своего диспетчера памяти.
• VCL компоненты написаны коряво, расширять их функционал неудобно. Для примера, все удобные, сторонние DbGrid-ы  не унаследованны от TDBGrid.
• Нельзя бросить на форму свой компонент, его нужно устанавливать, нет аналога Qt-шного "promote component". Поэтому вместо написания своего TMyEdit, люди обвешивают событиями стандартные TEdit.

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

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

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

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

[Winstrol]

Код:

[quote author=Smilius link=topic=9980.msg58486#msg58486 date=1247141656]
[quote]
Пример в студию, чем удобны Anchors.
[/quote]
Так сказано же - СРАВНИВАТЬ - НЕЛЬЗЯ!!! - это другое
С помощью якорей можно так же строить интерфейс, где меняются размеры и пр.

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

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

Имеется в виду один event - множество обработчиков. Мы в соседней ветке о многопоточности трем. В QT signals/slots
работают и в многопоточных приложениях, причем
-слот объекта другого потока может быть вызван синхронно в контексте текущего потока.
-слот объекта другого потока может быть вызван ассинхронно в контексте "родного"  потока объекта.
-слот объекта другого потока может быть вызван в контексте "родного" потока объекта с блокировкой текущего потока до обработки слота.

Как с этим в Delphi?
В С# аналоги есть.

[Sokoloff]

Неплохой редактор, не без недостатков но неплох. - после сцинтилоподобных очень неуклюжий.

Про редактор я наверное зря написал, здесь все очень индивидуально.

Очень хорошая документация. - категорически не согласен, документация Qt намного удачнее.

Документация по Qt хороша, но в делфи практически для каждой функции есть пример. Чего бывает не хватает в Qt.

Низкий порог вхождения - Я расматриваю инструмен по двум параметрам:

Скорость освоения - тут спорно, что лучше IDE (Делфи, Студия, ...) или консольные инструменты компиляции (make...)

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

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

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

Надостатки Delphi перед Qt и C++.

• Отсутствие множественного наследования, - ну в Qt виртуальное тоже невозможно, для наследников QObject
• В этом сравнении забыта локализация, крайне просто реализованная в Qt, в купе с концепцией компоновщиков, позволяет избежать ляпов, которые встречаются, например, при локализации того же Лазаруса (когда перевод на русский язык не помещается в виджет, т.к. его размер автоматически не подстраивается под окружающие виджеты и под внутренности)

Надостатки Qt

• Имена свойств размеров/компоновщиков, например, при визуально проектировании окна если задать виджету sizeHint = minimum, то он может увеличится, что не очевидно.

Согласен