Russian Qt Forum

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

то, что в дельфях давно пройденный этап, в QT преподносится как супер прорыв, даже слёзы умиления выступают.
IT-индустрия постоянно ищет баланс между простотой разработки и эффективностью кода.

хочешь эффективности - пиши на сях, но будь добер изучи как там что под капотом у компа крутится, иначе никак.
хочешь чтоб кинул кнопко на формо и оно уже работает через 5 мин, пусть и НЕ ТАК эффективно, пиши на дельфях.
и тогда что там под капотом тебе пофиг.

из-за того, что сейчас выгоднее что-то разработать БЫСТРО, пусть и МЕНЕЕ эффективно, т.к. конкуренты не спят, и появляются обертки для сей типа QT. Конечно, аксакалам это кажется сдачей позицией в пользу блондинок, но пусть они выходят на УЖЕ ЗАНЯТЫЙ несверхэффективной, но работающей продукцией блондинок рынок со своими сверх-супер-чуть-ли-не-ассемблерными продуктами, никто же не против :-)

я всю жизнь сидел на дельфях, на QT полез только по причине кросс-платформенности. где-то за месяц такое мнение имею:
по удобству для программиста - уровень примерно Delphi-1 (15 лет давности), по эффективности кода - те же дельфи-1, т.к. механизм слотов и сигналов напрочь хоронит фирменную сишную эффективность.

резюме: тот, кто сделает кроссплатформенную дельфю просто озолотиццо :-)

Ого какое у тебя мнение за месяц. Наверное ты уже ас и в Qt и в С++ :)

По поводу удобства - ниче если два различных языка используються  в либах? Лично для меня писать на С++ намного лучше/удобнее/быстрей чем на Object Pascal
По поводу слотов наверно доку не читал. Вам сюда http://doc.qtsoftware.com/4.5/signalsandslots.html#slots (http://doc.qtsoftware.com/4.5/signalsandslots.html#slots)


На счет кросплатформеного делфи - почему то вы забыли про такое чудо как CLX

бред =(

let's flame begin! ;)


Примеры в студию


ололо. А где же факты? Что именно не удобно? Ты хочешь сказать, что программы написанные на Qt уступают по скорости Delphi 1? Неверю. Давай цифры


Kylix?

ЗЫ: Тему почишу

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

Из всего что я пробовал за последние 10 лет (Делфи, MFC, Билдер, wxWidgets, Visual Basic, Labview) для целей разработки визуального представления данных получаемых с оборудования и управления обородуванием.

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

Лидер по скорости освоения - Qt (особенно слоты и сигналы, т.к. с электроникой хорошо ассоциируются).

моё резюме: золотая середина - Qt.

плюс пиццот! :)

ну мы тоже с оборудования ЖКХ сигналы обрабатываем и тоже на QT вышли и не жужжим, но основной ништяк ловим от кроссплатформенности, т.к. ЖКх-шная москва потихоньку на ubuntu переползает.

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

вот что в доке:
In general, emitting a signal that is connected to some slots, is approximately ten times slower than calling the receivers directly, with non-virtual function calls.

мой опыт преподавания у молодежи говорит, что си ГОРАЗДО менее интуитивно понятен современным вьюношам.
все-таки если зарубаться на связку "время освоения+время написания", то из 100 студентов 99 быстрее дойдут до финиша на паскале. в условиях рынка реального времени и крайней желательности делать проекты силами не гуру а вчерашних студентов
си БЕЗНАДЕЖНО проигрывает многоборье. Хотя отдельные виды (работа с железом и т.п.) спорта он безусловно выигрывает.
и мне он нравится именно своей архаичностью, "стругацкостью" в конце концов. и вообще, молодость напоминает, когда и мы были рысаками :-)

CLX говно имхо

Насчет генеев целая куча недопрограмистов которые тонут в пониманиях что такое работа с указателями или что такое ООП. Не раз встречал людей которые могут склепать тебе формочку со всеми обработчиками но при этом не понимают что такое Классы ни концепций ООП вобщем :)

О да паскаль... О какой из версий по дискутируем? Какая часть этих "вьюнешей" понимают что такое указатель и как с ним работать?

На счет того что CLX гавно не спорю, но за то явно подчеркнуло возможности делфи в кроссплатформености.

Напомни ка мне пожалуйста на сколько меделнее работает код на делфи чем на си :)

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

А вот если бы я продавал какие-то компиляторы, тогда канешна .. :-)

так паскаль создавался ж вроде как ОБУЧАЮЩИЙ язык программирования... в нем нету того что есть в Си ! и дело не в синтаксисе!

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


вот именно! язык для обучения! :)

Ну да, 2 года вычитывать курс Pascal + 1 год Delphi, потом за семестр прочитать курс С\С++. Какой язык они освоят лучше (если конечно освоят)? Да, будут что-то писать на С\С++, но в стиле Pascal. При этом будут материть С\С++, мол "язык ацтой". Более того, во многих ВУЗах сами преподы не знают С\С++. Что они могут рассказать и преподнести студентам? Правильно... ничего...

Вот-вот. Откуда берутся быдлокодеры, загадка прям ))). Да, это одно, накидать на форму кхампанент, а код кто писать будет? Или уже есть такая кхампанента для Делфи?

Вот ак объективно, скажи, какими недостатками обладает Qt Designer по сравнению с дизайнером Delphi?

все очень просто. благодаря крутым IDE-шкам время блондинок пришло и в область программирования.
очень сильно напрашивается аналогия с женщинами за рулем. раньше их тоже вроде как не было.
но благодаря коробкам-автоматам, куче автосервисов и т.п. ДАЖЕ блондики могут ездить и ездить ПРИЕМЛЕМО
для обычных городских условий.
так же и в IT - даже не зная ООП и не понимая, глядя на сишный for, что это именно for, а не издевательство над while,
уже МОЖНО писать КОММЕРЧЕСКОЕ ПО, как ни странно :-( и ни обидно.
программирование из искусства превращается в ремесло, и это нормально в общем-то

это даже не смешно. только в ЧЕТВЕРТОЙ версии из-под дизайнера ДАЖЕ можно стало компилить проект.
напоминает анекдот про бассейн, в который нам даже нальют скоро воду, если будем себя хорошо вести :-)

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

Эм на помни как мне где мне кнопочку нажать в дизайнере чтоб у меня проэкт скомпилися?

Вы случайно с автором топика не братья? По тому как я смотрю ты тоже IDE с Framework'ом путаешь

И вобще ты ругал либу а не IDE. Я до сих пор не услышал довода по поводу чем хуже к примеру Qt чем VCL?
и раз ты так уж начал кидаться в разные стороны так давай разграничим темы. И так у нас их уже 3

1 Object Pascal/Delphi(как язык) и С++
2 Delphi(как среда разработки) думаю здесь можно поставить QtCretor(делаем скидку на возраст)
3 Qt и VCL

по мнению одного шапочно знакомого спеца (реально спеца!), в ВУЗАХ надо вообще давать VBScript и WSH для пропитки студентов правильным подходом. А остально сами пусть добирают. Судя по вакансиям, наиболее нужен щас PHP и все такое.
то есть нужны не спецы по языку, а некие люди-губки, быстро могущие освоить ЛЮБОЙ язык под конкретную задачу

Можно оффтоп ? Спасибо =)
Казалось бы а при чем тут Qt? Сначала вы говорите что qt это delphi 15 летней давности
и приводите аналогию с автосервисом и блондинками. Затем съезжаете на студентов-быдлокодеров
которые не понимают что под капотом. Теперь приводите пример ide, к чему вообще это все ?
Только насчет qt вы погорячились, студенты которые действительно учаться на программистов, а не
тупо ходят в институт потому что мамочка отправила или потому что так получилось, они ведь
все равно придут к тому что под капотом и рано или поздно дойдут до вашей же точки зрения и
все станет на свои места. Так к чему продолжать эту тему ?

ну тогда вынужден вас обрадовать - в таком случае никакого дизайнера дельфи нет. там с самого начала все связано, и это УДОБНО. хотя возможность работать с одним проектом в разных IDE-шках меня восхищает, в мире дельфей этого нет, т.е. проект дельфи мы можем курочить только в дельфи, и всё.

>>Вот ак объективно, скажи, какими недостатками обладает Qt Designer по сравнению с дизайнером Delphi?
Для меня первый затык был в прнципе размещения виджетов. В Борландах используются якоря (какой-то край к чему-то приклеиваешь), а в Дизайнер компоновщик, что просто крайне не привычно.

когда я порешал кросплатформенно програмировать, то решил, что буду только в коде, чтобы понять.
Тем более, что С++ знал только по наслышке.
Qt позволила мне разобратся с самим С++, наглядно и довольно быстро .
Чуть позже вернулся к Билдеровской проге и стало очевидно, что в билдере, на мой взгляд не С++'ный подход к работе с классами, а чисто дельфийский.

ну, модер перенесет тему в какой надо раздел.
мне лично QT нравится. всем рекомендую, особенно РАБОТАЮЩИЕ демо-примеры душу греют, и хелп просто потрясающий.
я как реально отставший от всего прогресса, на это тем более имею право так говорить, т.к. без хелпа просто никуда

бальзам на душу. и у меня те же ассоциации. QT-creator даже начинает реально нравиться. Думаю ,что для популяризации сей эта IDE еще очень много сделает

Если уж говорить именно о IDE(не о языке и библиотеках ) то QT-creator и близко не стоял в сравнении с Builder.
QT-creator вещь полезная, но ему еще долго расти, чтобы приблизиться по функциональности и удобству к Builder.

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

И ещё хотелось бы получи ответ на то, какие все таки застарелые технологии используются в Qt и котороые уже были в Делфи 15 летней давности

Заметь что я написал в скобках
Так же все таки хотелось услышать какой все таки функционал в дебилдере круче :)

С ужасом вспоминаю времена, когда я "программил" на билдере. Писать не понимая основ - это не программирование.
А Кутя заставила выучить язык и понять, что на самом деле делает моя программа.
VCL уступает Qt хотя бы по кроссплатформенности. А вот в чем Qt уступает, даже не знаю. Может объясните на пальцах?

В QtCretor его пока мало, так что сравнить не удастся :)
Да и заниматься что-ли мне больше нечем, кто писал(достаточно долго), тот меня и так поймет.

Писать не понимая основ(особенно начинать программировать), можно хоть на чем, это к сожалению проблема большинства программистов. И билдер здесь уж точно ни при чем.

И все же ты кинул реплику так давай аргументы. А так ответ похож на что то подобное Лучше потому что лучше, а кто не согласен нифига не знает. Тут только аргументы нужны ;)

Я уже сказал, у меня есть занятия по интереснее.
Поработай в билдере несколько лет, а потом открой Креатор и поймешь разницу.

Вы как-будто в холиварах не участвовали :) Тут аргументы не в почете, позицию раскрывать до конца нельзя, прямо отвечать на поставленный вопрос - это дурной тон, а сама суть в выставлении собеседника невеждой, который не может свести в уме прописные истины :)

Я уже десять раз пожалел о том что вступил в дискусию, на самом деле в спор.
Просто почитал сообщения много фанатичного отношение к QT и сопутствующим приложениям.
Спорят те, кто билдер либо вообще не открывал, либо сделал в нем пару форм. А Креатор, конечно "круть" он же троллевский.
Xорошо, привиду только одно простейшее сравнение. Вспомогательные окна - их настройка, имненеие расположений, сохранение их конфигураций.

я , как затеявший эту бучу, докладываю --- 2мя руками за позицию BORIONAK!
нельзя рафинировать свою работу узкоспециальными работами, в жизни всё шире.
так можно и без штанов остаться, на всех не хватит глобальных проектов со штатом в десятки программистов по комп. софту, отдельно схемотехников, отдельно программеров по железу.
сделать интуитивно понятную вещь ---удел *гениев*, а напустить туману и сослаться ---вы тут все дураки, а я один умный.....большого ума не надо, сам клиентов развожу.....
поэтому---borinoak ---+5

btw, неужели никто не слышал про Lazarus (http://ru.wikipedia.org/wiki/Lazarus)?

Да ладно вам, никто же здесь вас не троллит тонким образом, наслаждайтесь :)

Все же добавлю огня. Я работал с Delphi 7/2006 несколько лет (не билдер конечно, но они во многом сходны), и мои впечатления в корне отличаются от ваших.
Во-первых серьезные проблемы со стабильностью среды: падения среды при старте отладчика? по 5 раз на дню; при отладке библиотек очень часто отладчик просто не желает останавливаться на брейкпоинтах; а редактирование окон с фреймами оставляет травму на всю жизнь.
Во-вторых очень слабый редактор кода, я серьезно, возьмите любой редактор и он будет лучше.

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

Они уже дописали LCL до уровня D7? Когда я пробовал версию 0.9.24 ничего сложнее 3KLoC портировать не удалось (при этом пришлось отказаться от JCL)

а вообще дискуссия идёт правильным путём---узнаёшь о событии которое может произойти при наступлении на данные *грабли*=софт.
полезо делиться житейским (профессион.) опытом :D ;D ;)

это маразм, не спорю, но по факту очень многие в моей сфере работают без всяких там "вражеских примочек" типа ТЗ, UML и т.п.
да, да - даже без ТЗ!!! Рынок, вал, быстрее, придумай сам чонибудь, и прочий ужас. Как хорошо, что я не пишу автопилоты для самолетов. К сожалению .понимать досконально, что же твоя программа делает - это уже роскошь при работе в режиме потогонки. реалии таковы, что приходит шеф и говорит - завтра ведем с клиентами беседу  о живописи на китайском языке, а
ты ночью читаешь что такое живопись :-( а по пути на беседу просматриваешь по диагонали русско-китайский разговорнег

дык для того и пхорум :-)

Хоть уже все писали - но все же - не согласен в Корне. Мне кажется автор сухой теоретик не представляющий вообще о чем он говорит!

Я 2 года работал в фирме и пользовался Delphi 2005, 2006 лицензионными. 3 Вылета в час - стабильно. Кроме того Delphi развивает неправильный подход к программированию. Люди начинают думать мол накидал на форму кнопочек и все будет ок. Нет на самом деле такие "программисты" никому не нужны и студенты не способные разобраться с Qt никогда не станут программистами.

Вообще я не страдаю способностью влюбиться в то чем пользуешься и потом все делать на этом. Работая в разных местах и выполняя разные задачи приходилось пользоваться разными IDE и языками. Но с первых дней Qt привлекала все больше и больше - т.к. многие вещи там сделаны для людей. Взять к примеру класс QString - в нем есть практически все что нужно делать со строками - а в делфи я еще во времена 2006 писал свои  функции для разбиения на подстроки, с учетом разделителей. Почему этот столь полезный функционал не имеется ни в одной стандартной библиотеке? Да вообще считаю что Delphi стала популярной просто вовремя попав в "струю" - во времена D5-D7 ей просто не было конкуретнов. Действительно MFC сложнее - все остальные библиотеки если уже существовали то были слабенькие. Сам я работал начиная с D1 и до D2006 - для меня наиболее удачная и стабильной была среда D7. Механизм дизайнера форм - с его алигнами намного уступает Qt-шному Дизайнеру форм. Я реально могу это оценить т.к. работал над проектом где требовалось создать на экране сенсорного монитора имитацию реально существующего прибора - на котором имеется куча стрелочек, кнопочек, меняющихся подэкранчиков - более 60 разных компонент. Половину из которых еще и надо было самому написать. Так вот при работе с Делфи это было мучение. Сейчас с Qt все вполне норм.

В Visual Studio работал мало. Сейчас работаю с Qt в среде QtCreator - считаю ее очень удобной, до этого использовал KDevelop. Специально интересовался у программиста также перешедшего на QtCreator после долгой работы с VisualStudio - он сказал что "студию можно сделать такой же удобно как креатор - наставив платных плагинов расширяющих функционал IDE".

Наиболее удобные в креаторе вещи для меня которых нет в других IDE:
1) Ctrl+K - сов всеми возм-стями поиска файлов, классов, методов и т.д. - очень удобно
2) Механизм поиска и замены с подсветкой как в опере - вообще супер.
3) Механизм выборки результатов поиска по проекту - с возможностью последующего прохода по этому списку - также постоянно пользуюсь

Про всякие там CodeCompletion и Go To Definition я даже не говорю - это 100% должно быть в IDE - хотя в делфи это всегда отваливалось.. после часа работы

Иногда доходит до того что я открываю креатор чтобы какой-то xml подправить - заменив там кучу значений атрибутов.

Оффтоп:
Шутки по поводу блондинок совершенно не уместны - женщины вполне адекватно водят машины - гораздо чаще правильнее и порядочнее чем мужики. А дураков среди всех людей хватает. Только у мужиков проблема - называемая комплекс неполноценности заставляющая подрезать, обгонять, нарушать, и этой проблемы в большинстве случаев нет у женщин. Если на то пошло это только в России женщины за рулем долго не было - на западе каждый человек с 14 лет водит машину и это не считается ни чем особенным. Как то видел фото - машина с втсавленнным пистолетом заправщика(оторванным) - и надпись "it's a woman" - а недавно товарищ рассказал как мужик оторвал на заправке этот пистолет прямо у него на глазах и поехал даже не остановился!!! Так что нефиг над блондинками шутить это глупо.

2 break---спасибо за развёрнутый ответ!

Qt дает удобнейший инструментарий для создания по сути любых приложений. При этом это еще качественно и быстро. Что еще нужно?

Сравнение IDE и прочих гуевин к оному.. Кутяшники сделали все просто, и это правильно. Единственное, чего реально не хватает в текущем Creator'е, это папки-фильтры в отображении файлов проекта (странно что нету, хотя с помощью .pri файлов легко делается ручками) и сохранение "свертываний" кода.

Визуальные билдеры не люблю. Они нужны чтобы "клепать" некоторые вещи, особенно любимые офисные менеджеры и т.п., где главное чтобы поля и кнопочки были нужные. Сам билдеры визуальные не пользую, ибо к коде все удобней.

Говорить Qt - плохо и "старое".. ну нафиг. Чего вы добиться то хотите? Каждый др..ет как он хочет. Главное - конечный продукт. Смотреть на кучу дерьмоаппэшэк, сварганенных с помощью дельфей - достало до жути.

Обучение студентов и т.п.. Реально, вначале Паскалем мозг имеют, потом неясно как дают си пэ пэ, когда часто препод сам имеет четкое мнение "как надо"..

Холивары..

2 UNFA---я так понял--вы софт пишете лично для себя либо друзей прогеров?
а чем же на жизнь зарабатываете? ;D ;D ;D

+100 хоть и оффтоп  ;D

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

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

Хм, интересно на чем основано ваше мнение?

У меня креатор не тормозит и скорость компиляции вполне приличная. К примеру - в сумме по всем подпроектам всего 320 cpp файлов - полная пересборка около 2-х минут. В чем у вас тормоза? Неужели в текстовом редакторе курсор медленнее мигает?
----тут глупо сравнивать компиляцию паскаля и с++ - Да почему глупо? В Дебаге они сравнимы вполне! Может вы все время в релизе собираете? Или можеть у вас в каждом файле написано include <QtGui>?
Мое субъективное мнение что креатор быстрее чем делфи работает - елси сравнивать скажем code completion - больше даже не знаю что сравнить...

---И еще в QTWebkit очеень криво с флешем в линуксе работает
на счет этого ничего сказать не могу, не работаю с WEB, но флеш плагин в линуксе у меня вообще очень плохо работал - постоянно вешая оперу, пока я его не снес...

На какой машине инетересно ) Предполагаю что в дельфи такой проект будет компиляться секунд 20-30 )


Речь идет о разборе синтаксиса, например в C++ можно переменную объявить в любом месте а в паскале нельзя.  В результате разбор кода паскаля значительно быстрее

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

Ну тут ведь Вы сами все понимаете - за скорость компиляции расплачиваются тормозами в runtime.

У Делфи есть одно существенное преимущество - богатейший набор сторонних компонент. Если бы в Qt был аналог QuantumGrid от DevExpress я бы уже выкинул этот Delphi как страшный сон (глюкавое тормознутое чудище с каждой новой версией становящейся все тормознутее и глюкавее). Но пока его аналога нет (одна возня с иерархическиеми заголовками грида тут на форуме чего стоит - на DevExpress делается в два тыка), и приходится мирится с Delphi.
Кроме того совсем не в пользу Delphi, регулярное шараханье Borland Delphi -> Delphi + Kylix -> Delphi.Net -> Turbo Delphi -> CodeGear Delphi -> Delphi.PHP -> Embarcadero RAD Studio. И каждый раз заново - то движок БД сменят (BDE -> ADO -> MIDAS -> dbExpress -> сейчас уже и не знаю чем они пользуются - ушел в FIBPlus и забыл про все), то начинают пихать Delphi во все возможные дыры типа разработки Веб-приложений (CGI, ASP-модули, Apache модули). Все это на ходу производителями бросается недоделанным, они кидаются в новую для себя область (CLX, JBuilder, .Net, .PHP, Prism), а разработчику остается только охреневать от такого.
А бинарная несовместимость на уровне объектных файлов от версии к версии? А приобретение/открытие исходников/их закрытие Interbase? А величайшее достижение - поддержка UNICODE в 2009 году? А отсутствие 64-битного компилятора в 2009 году? А использование ВИЗУАЛЬНЫХ элементы формы для ХРАНЕНИЯ данных?
В общем, как бы не было обидно, но Delphi - это что угодно: удобная среда ОБУЧЕНИЯ программированию, замечательное средство клепания программок на скорую руку, мечта шароварщика и .т.п., но это не средство ПРОМЫШЛЕННОЙ разработки серьезных проектов.

Да лано вам спорить уже :) Мир, дружба, жвачка! :D

У меня на бывшей работе было 10000 сотрудников, расчет заработной платы написан на дельфи )

О чем это должно свидетельствовать? О том, что люди, разрабатывавшие приложение, успешно преодолели все злокозяки Дельфийские - ну так и молодцы. Тем более, что я не говорил, что с помощью Делфи НЕВОЗМОЖНО промышленно программировать - я говорил, что оно (или она?) для этого НЕ ПРЕДНАЗНАЧЕНА, хоть ему этого и сильно хочется.

Я не особо пока разбираюсь в QT ) больше для линукса ) Но например в том расчете были использованы такие технологии как Windows Services и DCOM. На QT можно написать сервис виндовый или ком объект?
Хотя ком то можно хоть на чем реализовать..вопрос желания )

И что что это доказывает? НИЧЕГО - даже на ассемблере можно было бы эту программу замечательно написать - вопрос за какое время, сколькими специалистами и какого уровня. А так я уверен даже из говна можно фигурки классные лепить - а уж делфи как никак инструмент, по крайней мере изначально был. Вы бы лучше сообщили впечатление пользователей о программе или разработчиков о делфи...

Моя машина Core 2 Duo 2.8 4Gb - неплохая конечно, но я сказал полная пересборка проекта - а реально там 30 подпроектов - отдельно виджеты, отдельно библиотека для работы с БД, отдельных программ несколько - все линкуется динамически - реально работая над одним модулем я меняю 1,2,3,10 CPP файлов - и компиляция у меня происходит 1,2 - максимум 10 сек. Так что пофиг что там делфи... то же самое...


Да компонент немеренно - но большая часть из них ублюдские - да еще и за деньги - то что назвали вы (DevExpress) это хорошая библиотека - там помойму и дерево и таблица - все замечательно - но опять же они платные!!! И это не достоинство а недостаток купив делфи я не получаю эти компоненты - а если завтра разработчики перепишут их на Qt - я куплю такие же кутешные. А на счет ребят на форуме которые написали хитрый headerView - да замечательно и пользоваться им не сложнее QuantumGrid-a(я качал себе этот headerView)  вы просто к нему привыкли и разобрались я в свое время смотрел его и мне EhDbGrid показался проще, обладая всем необходимым, да еще и бесплатный он. Со временем компонент для Qt станет не меньше чем для делфи - уже появляются замечательные вещи.

В остальном я с вами согласен!!!

Для обучения написания компилятора Паскаля, но не для обучения программированию. Для последнего он слабо годится.
[/quote]

>>На QT можно написать сервис виндовый или ком объект?
Да

Замечательно годится и для этого создавался. Я сам учился программировать на нем еще на очень старой машине - писал код в текстовике и запускал внешний компилятор, потом работал в Делфи (тот же паскаль улучшенный), переходя на C++ особых проблем не ощутил - т.к. программировал не на делфи а на Objects Pascal до этого - по сути все то же самое Процедуры, функции, объекты, методы, указатели, контейнеры - какая разница - все понятия очень схожи, а к новому синтаксису привыкнуть надо 2 недели. Конечно много новых аспектов есть в C++ - но большая их часть связана с оптимизацией а не с организацией программы, большинство шаблонов проектирования можно использовать в Паскале-Делфи также как в С++. А если человек программируя в Делфи не понимает что такое класс объекта и что такое экземпляр класса объекта - а потом приходит в С++ и там с учетом того что такие вещи надо четко понимать - вообще для него настает ж.....па. И он думает ах какой плохой был паскаль совсем меня запутал - или какой плохой ц++.

Ну вот и замечательно - а уж программу расчета зарплаты на Qt точно можно написать, учитывая что пол программы будет БД.

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

Пользовали? А что пользователи ) они нажимают главную кнопку ТЫЩ (расчет) и начинает работать программа расчета, лезет там в оракл и прочее ) и через несколько часов заканчивает работу )

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

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

Профессор Вирт написал Паскаль чёрти когда, с тех пор он минимум дважды координально усовершенствовал язык.
Паскаль - императивное програмирование
Модула - модульное (ни Си ни С++ до этого не доросли)
Оберон - объектно ориентированное програмирование.

Когда преподователь в ВУЗе лепечет об ООП на паскале хочется ему в ухо двинуть.

Не понял мысль.

А если нет? Для Делфи-то они уже написаны.


Ну тут-то я буду только - за.

Ваше отношение к пользователям понятно - пофиг удобно или нет, вылетает или нет и т.д.
Я в свое время работал с программой (устанавливал и настраивал ее вместе с БД) Тандер-Склад - она тогда была написана с использованием BDE - и вылетала в случайные моменты времени из-за ошибки выделения памяти в BDE - и никакая куча делфийских специалистов не могла решить эту проблему т.к. не BDE нет исходников - с Qt другой подход все исходники на местах. Решение было - уход от BDE - а так как программа была огромна - директорам сети магазинов приходилось по 3 раза на день вбивать накладные.

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

Вы привели пример что к Delphi куча компонент как ее достоинство - а так как они к ней комплектом не идут, а надо их купить отдельно - то я в этом достоинства не вижу. И если прикинуть сколько стоит набор компонент полноценный для создания программы БД - то это грид+дерево (к примеру DevExpress), генератор отчетов (FastReport), компоненты доступа к БД (FIBPlus) - все это за отдельные бабки! Мне совсем не нравится такой подход уж лучше в моей программе пока компонеты будут попроще с перспективой дальнейшего их улучшения. Если не платить деньги за эти компоненты а нанять еще одного программиста кот. напишет грид для Qt?
Тем более уверен всеми особенностями QuantumGrid вы не пользуетесь - уж слишком он пузатый.

Годится? Ой, врете
google: pascal lecture notes site:edu .
Вместо Pascal по вкусу: scheme,C,Java.

Ну и про создавался тоже самое, если интересно, гугл в помощь

Кстати, не в теме последних версий Delphi. Там layout manager'ы из QT уже украли или еще нет?

**Визуальные билдеры не люблю. Они нужны чтобы "клепать" некоторые вещи, особенно любимые офисные менеджеры и т.п., где главное чтобы поля и кнопочки были нужные. Сам билдеры визуальные не пользую, ибо к коде все удобней.

Говорить Qt - плохо и "старое".. ну нафиг. Чего вы добиться то хотите? Каждый др..ет как он хочет. Главное - конечный продукт. Смотреть на кучу дерьмоаппэшэк, сварганенных с помощью дельфей - достало до жути.**

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

Это ты к чему? Я привел пример собственного опыта программирования - благо пока с работы не выгнали - у меня был под рукой только паскаль и хотелось учиться программировать - и это на том этапе получилось - что ты мне написал я даже не пойму... Я конечно за интернет технологиии - но ты у гугла не слишком ли много спрашиваешь?

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

Ключевая фраза "был только Паскаль".

Нифига не понял, честно :) Это утверждения или выводы?

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


Не придирайтесь к словам я тогда попробовал и бейсик(как сейчас помню интерпритатор из DOS 3.30 qbasic.exe назывался) и турбо ассемблер (даже немножко писал на нем) и турбо си - но паскаль наиболее оказался подходящим для меня для обучения - потому что - что такое begin и end понятно без объяснения а что такое {} - надо еще и прочитать в руководстве, и хотя я сейчас по всем параметрам и даже синтаксису предпочитаю C++ мне каж-ся паскаль хороший язык для обучения до определенного этапа - именно язык паскаль а не среда Делфи. Например в С+++ легко спутать при объявлении переменную и имя функции в Паскале именно из-за синтаксиса такое невозможно. Надеюсь если вы что-то ответите то уже свои реальные доводы а не отрывки страниц поиска из гугла.

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

2 borinoak, про звёздочки и стрелочки - это на самом деле простые вещи.
На память вот одна ссылка: Точка или стрелка? (http://www.forum.crossplatform.ru/index.php?showforum=11)

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

Вспоминать Паскаль лениво.
Ну допустим, как объяснить новичку в программировании, что код складывающий килограммы нельзя использовать для скложения рублей?
Отсутсвует (или есть?) препроцессор для сокращения лишней писанины.
Почему нельзя написать как в C#: var x=3.14 ... var x=y? Получается вроде как строгая типизация есть, но не для человека, а для машины. Нетривиальные полезные свойства строгой типизации для сокращения повторной писанины никак не задействуются.
 
Это достоинство является следствием недостатков Паскаля. Более простая грамматика легче воспринимается не только глупой машиной, но и новичком. Сишный синтаксис сложнее, т.к. язык эволюционировал в процессе промышленного применения, а не изобретался на бумаге.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Насколько я понимаю человек хотел сказать что в 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 с которым я работал - это семерка, может в новых что-то исправили, добавили.

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

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

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

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

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

Надостатки Qt

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

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

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


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

Property XXX

Description: this is the property XXX of YYY class.



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

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

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

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

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


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

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

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

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

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

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

Согласен

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

Причем здесь это? Я говорил о другом. 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.delphikingdom.com/asp/viewitem.asp?catalogid=168)
http://www.citforum.ru/programming/delphi/nogrid/ (http://www.citforum.ru/programming/delphi/nogrid/)

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

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


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

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

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

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


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

Большущий +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 лет вы так и уклоняетесь или я пропустил этот момент ?

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

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

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

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

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

Здравствуйте, сейчас 2009 год, STL была принята в стандарт языка 11 лет назад :)

+5

>>вроде передачи параметром функции, присваивания, суммирования, foreach, динамической размерности и.т.д.
Вот поэтому народ и пишет на Qt. (foreach (http://doc.crossplatform.ru/qt/4.5.0/containers.html#the-foreach-keyword) в частности  в ней есть :)

Угу, который, если не ошибаюсь, является макросом :) При желании можно и свой написать :)

Уже написали :) BOOST_FOREACH (foreach.hpp, 1KLoC)

Дык foreach реализован через цикл, а значит создает ненужные зависимости между итерациями.
Например,

C++ (Qt)
for (int i=0;i<100;++i)
{
    x[i]+=f(x[i]);
}
 

компилятор в общем случае не сможет переделать в

C++ (Qt)
for (int i=0;i<100;i+=2)
{
    t[0]=f(x[i]);
    t[1]=f(x[i+1]); 
    x[i]+t[0];
    x[i+1]+=t[1];
}
 

т.к. f может содержать "криминальную" зависимость от предыдущего элемента.

C++ (Qt)
void f(double& a)
{
double* t=&a;
return t[0]+t[-1];
}
 

C++ (Qt)
а операции вроде 
x[i]+=t[0];
x[i+1]+=t[1];
 

выполняются почти параллельно на процессорах с конвеером.

Приходится использовать ключи типа whole program optimization \ link-time code generation, чтобы компилятор лез в другой файл, чтобы увидеть, что в теле f ничего криминального. Отсюда растет время компиляции и.т.д. А всего-то надо оператор, семантика которого не зависела от порядка работы с элементами массива.

>>return t[0]+t[-1];
я что-то такую криминальную зависимость совсем не понял

Результат зависит от порядка обновления элементов в foreach.

А отрицательный индекс в масиве?

Это не отрицательный индекс, это элемент перед t.

От нахоливарили! :)

Уже столько раз всё это обсасывалось, что что-то писать по новой лениво.
Замечу только, что практически всех дельфяников при встречи с Qt берёт оторопь, и они начинают возмущаться какое это отстой и старьё.
Парадокс Блаба (http://www.rsdn.ru/article/nemerle/Amplifier.xml#EEB) в действии. :)
Примечательно, что практически всех из них, кто продолжает работать с Qt дальше, через месяца 2-4 начинает раздражать неудобство работы в Delphi по сравнению с C++ + Qt.
Хотя об этом уже не так громко говорят. :)

+1!

Коллеги, понравился ваш спор и решил тоже тут отметиться. Qt очень хорошая библиотека
и думаю она скоро станет де-факто стандартом для разработки GUI в C++. А точнее уже стала. Но Delphi в настоящий момент имеет ряд преимуществ. Вот те, которые мне видятся:

- В Qt нет возможности использовать исключения.
- Qt дизайнер и концепция сигналов слотов не позволяет сразу сгенерировать обработчик в сырце для кодирования.
- У Qt дизайнера нет возможности добавить на форму не визуальный компонент.
- Qt требует наличия рантайма в виде QtCore, QtGui и т.д. (хотя это частично можно обойти статической линковкой)
- Скорость сборки приложения на Qt в разы медленнее, чем на Delphi. К примеру, сравните скорость ребилда Qt и VCL,
  для случая, когда вносились изменения сами эти библиотеки.



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

Оператор ":=" в Паскале это присвоение, чтобы отличать от оператора равенства "=".
В С++ тоже отличается, "=" и "==".

Согласен с топикстартером, что кросплатформенный нативный Delphi (не NET и не CLX) может озолотить :)

Ты имеешь ввиду что сама Qt не использует исключения?

А это надо?

Зачем на форме не визульный компонент? На форме нужны визуальные - форма она на экране.

Не знаток делфи... А там библиотеки никакие не используются. Может стоит глянуть в зависимости.

:)

Используются конечно =)

Использование Qt подразумевает знание C++. Чем лучше знание C++ и принципов функционирования ОС, тем меньше недопонимания про скорость сборки (которая зависит только от компилятора), отличия рантайма от зависимостей, механизм исключений и т.д.

Qt - это просто C++ библиотека. Дизайнер - просто помощник создания нудного кода. Все остальное - это достоинства и недостатки C++.

Почему нет - есть иcключения C++ берите и используйте

Уже человек возмутился по этому поводу, но я тоже не могу промолчать - вы просто привыкли кидать на форму всякие DataSet-ы и кликая мышкой связывать их с DBGrid-ами. Когда-то я тоже так делал - теперь с Qt не делаю - и на форме у меня нет абсолютно бессмысленных значков этих самых невизуальных компонент...

зайдите в системную папку и там поищите файлы *.bpl - вас удивит но рантайм делфи больше весит чем рантайм Qt.

Бред это все - они попытались это сделать, - собственно получился CLX - кот. почти точно повторяет архитектуру VCL с ее недостатками.

А если делать что-то толковое - то Qt получится.

Оффтоп:
Правда ли что CLX была реализована с помощью Qt, а Kelix запускалась из под wine? - Собственно это не я придумал а однажы увидел в какой-то статье по сравнению систем разработки. Прошу знающих людей подтвердить или опровергнуть!

Да CLX действительно был реализован по верх Qt - но только под Linux.  На сколько я знаю Qt использовалась как чисто GUI lib т.е. только для создания окошек, кнопочек и т.п. При этом поверх Qt был еще один шар API
Насчет Kylix такое впервые слышу :)

Пожалуй соглашусь, что скорость сборки наверное это спор про С++ и Pascal и к делу не относится.
Я имею ввиду, что в Qt проектах не принято использовать исключения так как базовый фрейморк
под них не заточен.

Вопрос не про то, кто как делает или не делает, а про то что есть факт - нет поддержки не визуальных компонент в дизайнере. Вы сейчас это не делаете в Qt так как этого нет, а если эту возможность предоставят в Qt5, то уверен пользователи найдутся.
Насчёт зависимостей, вот у меня есть два скриншота - один зависимости бинаря собранного в Delphi7, а другой зависимости Qt демки. Но я не знаю как их тут выложить.

Могу немного дополнить. CLX сделан действительно поверх Qt3..x. В Windows и в Linux требовался
Qt рантайм. Поверх этого Qt рантайма был сделан "C" мост. В его задачу входило избавиться от C++ классов, так как Delphi не мог линковаться с C++. Например QPainter::draw(...) превращался в QPainter_draw(QPainterH*p, ...) и тд. И уже поверх последнего моста был реализован CLX.
Kylix запускался из-под Wine, а сама среда была написана на чистом VCL. Компилятор был нативный.

Если мне нужно (я хочу) использовать исключения, то я их использую...
[Задумчиво, мысли вслух: "Не принято.... кем не принято? почему не принято?"]

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

Вот с удовольствием взлянул бы.
Нажми на "Дополнительные опции..."

Насколько я понял тролли не смогли обеспечить обработку исключений единообразным образом на всех компиляторах, которые
поддерживает Qt. Поэтому отказались. Это значит что если вы вот так просто будете их использовать,
то возможно нарвётесь на проблемы под Linux или Mac.
Скорее политикой бывшего Borland......:) Идиология Qt и VCL по сути одна. Объектные модели очень похожи.

BRE --- я за твой пост +500

BigZ -- с тобой пока неочем разговаривать твой разум переполнен космическим трешем

Не знаю. Обработка исключений четко прописана в стандарте C++. Если какой то компилятор еще не умеет с ними работать, то это проблема именно этого компилятора, а не Qt.

Идиология делфи в том, что форма главенствует и на нее пытаются добавлять функциона совместно с GUI. IMHO это не очень удачная мысль.

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

Видимо проблема в том, что не все следуют стандарту.
Есть подход, который можно использовать, а можно не использовать.
Например вот, человек писал, что он кидал на форму DataSet, а потом перешёл на Qt и понял как он
ошибался. А что мешало ему сразу не кидать DataSet на форму а писать ручками?! У Delphi идиология - Rapid Software Development. У Qt  - Code less, create more. Кажется, что это где-то рядом.

Суть недостатка Qt была в том, что на Delphi+VCL я могу получить дистрибутив меньшего размера чем в Qt.
Для встраиваемых платформ вроде Delphi не умеет.

Идиология. :)
Думаю во всех книжках было написано, киньте DataSet на форму...

Для венды - да, но есть и другие платформы.
Сколько занимает места на диске венда? Не слишком ли это большой рантайм по сравнению с Qt?  ;)

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

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


А зачем еще нужен маленький дистрибутив если не для встраиваемых платформ?(жесткие диски копейки стоят) Кроме того сильно сомневаюсь что для Delphi он будет меньше - ты включи все сторонние библиотеки кот. прийдется использовать для хоть сколько нибудь серьезного проекта ведь в Делфи из коробки ничего не годится(имеются ввиду визуальные компоненты). А нормальные компоненты написаны без использования VCL.

Не слышал про VCL на других платформах, непонятно как сравнивать. Речь только про Windows.

Вот-вот. А Qt многоплатформенен, изначально. Поэтому я тоже не представляю как их можно сравнивать.

Первое, я не вопил, а спокойно говорил. Второе, в Delphi во всех учебниках сказано, что для невизуальных компонентов следует использовать специальную форму DataModule.
Вот первая попавшаяся ссылка на данную тему –
http://www.sql.ru/forum/actualthread.aspx?tid=135178. Если же нет времени и нужно быстро, Delphi позволяет невизуальные компоненты размещать вместе с визуальной частью.
Третье, нужно чётко понимать почему этой фичи нет в Qt, из-за идеологии или потому, что не хватило ресурсов и времени пока это реализовать.

Строки из скрипта конфигурации Qt
-exceptions ........ Enable exceptions on platforms that support it.

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

P.S. А вообще уважаемый, полегче на поворотах.

/* smiles */ А мне кажется что как раз при разработке Qt4 было время убрать невизуальные компоненты из дизайнера :) (Я с Qt3 не работал, но вкладка Databases на скринах дизайнера говорит о многом)

СКАЗКА - про отсутствие невизуальных компонент в QT !!!
=====================================
1) Визуальные компонеты наследованы от QWidget
2) QAction - не визуальный компонент
3) Соединение сигналов/слотов - тоже.
  ....

Просто в QT они так не называются, вопрос терминологии.
И в QT они пока строго определены и зашиты в дизайнер

Ну QAction немного относиться к GUI, что нельзя сказать про DataSet.  ;)
В дизайнере можно делать GUI (а можно и не делать!) - функционал нужно делать только в коде.

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

Просто время затрачиваемое на создание плагина невизуального класса неоправдано. А в борланде, если я ничего не путаю, без компонента хрен поработаешь.

Если QAction  относится к GUI, то к нему относится и QSystemTrayIcon, QIcon и еще очень много, все что имеет какое-либо визуальное представление. :D
Так называемые невизуальные компоненты в QT есть, просто они так не называются, и в дизайнере можно работать только с определенными.
В будущем, скорее всего этот список будет существенно расширен, просто дизайнер еще достаточно молод.

Ну QSystemTrayIcon еще как-то можно отнести к GUI, а вот QIcon я бы не стал (QIcon не имеет визуального представления).

Еще как имеет( визуального представление), иначе она вообще не была бы нужна.
Вопрос только в том что и как называть.
Разговор не о "отнести к GUI" что слишком абстрактно, а визуальных/невизуальных компонентах. Все что не наследовано от QWidget - не является визуальным компонентом!!!
И работа в дизайнере с невизуальными компонентами(Layout, QAction, сигналы/слоты, tab order, ...) есть, просто технология отлична от борландовской и весьма ограничена.
По мере развития дизайнера она явно будет расширена!

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

Вообще, разговор был о попытке в делфи сделать форму главной структурой, на которую напихивается и GUI и функционал. В дизайнере этого нет и вряд ли будет (я надеюсь).

Работал и в делфи и билдере. Не вижу приципиальной(идиологической) разницы между "DFM" и "UI".
И там и там можно делать формы как визуально так и в коде, отличаются только технологии, но не сама идея.
А по поводу напихивания функционала - в QT, например, сигналы/слоты, и еще слоты поумолчанию(при даблклике на button и action в дизайнере, примерно как и в делфях)

Разрешите тоже высказать свое ИМХО

Я писал и пишу(и нверное буду еще долго  :( ) на Delphi, но тем не менне с удовольствием сейчас изучаю c++ и Qt.
Самое замечательное для меня в Qt это возможность работать двумя руками используя простейший текстовый редактор. А Delphi, там все-таки три руки нужны  ;D

ну, в 1 руке мышь, в другой бутерброд, а 3я на что?

>>ну, в 1 руке мышь, в другой бутерброд, а 3я на что?
Дык, про пиво забыл

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

а DFM можно подгрузить рантайм?

это что-то новенькое...

QLayout не наследуется от QWidget, но является визуальной компонентой.
QPixmap - его нельзя положить на форму, но даже он является визуальной компонентой.

Вы ни одним своим ответом ничего не доказываете!

1) Что мне выложить кучу книг и уроков по делфи где не говорится про форму DataModule? - а взять к примеру DataModule - зачем он нужен? Чтобы проектировать логику программы мышкой кидая компоненты а не головой в коде. Так что это то же самое - по сути куча невизуальных компонент на форме. И я уверен при программирование на Делфи большинство людей кидает датасеты на рабочую форму а не на DataModule. И поддерживать потом такие проекты оч. трудно.

2) По поводу строк конфигурации эксепшенов - И ЧТО???? Qt существует давно когда может еще не все компиляторы поддерживали исключения - или может это вообще для мобильных платформ оставлено... Ничего не доказывает ваша цитата.. Есть в C++ исключения бери  и используй. В Linux и Windows работате 100%

3) Сейчас программы распространяемые через интернет уже не маленького размера - вы бы видели в каком количестве 15 Гб игрушки в steam качаются - может у вас dial-up? тогда да но у большинства людей минимум ADSL - 100М - 1 час - и что экономить мегабайты?

Вы просто цитируете все подряд не разобравшись

Я сам писал и сейчас пишу на делфях (около 10 лет), решил попробовать Qt. Как и у автора этой темы, через месяц изучения у меня возникло противоречивое чувство. Однако, через 3 месяца это чувство уже изчезло, а еще через полгода, я с одинаковой скоростью пишу проги как на делфях, так и на кути. Все дело в привычке и в навыке.

В общем я доволен, скорость работ программ написанных на кути гораздо выше, а самое главное - это кроссплатформенность.

Какие чудесные свойства, вообще о чем речь?
Да контернер для QPixmap.
Я приводил его в пример, поскольку может иметь визуальное представление(как-то опосредованно визуализироваться).

Нет, нельзя. Никто и не говорил что нет различий, речь шла про визуальное программирование.

Може называется подругому, не знаю.
Например:
Есть QAction MyAction;
Ecть слот: on_MyAction_triggered;

Нет необходимости делать connect.
  connect(this, SIGNAL(triggered (bool)), this, SLOT(on_MyAction_triggered()));
будут связаны автоматически;


А я вот не считаю QLayout  визуальной компонентой, где написано что это не так.
Опять же сравнивали дизайнер и делфи, в делфи есть понятие визуальные/невизуальные компоненты. Если переносить это на  QT, то визуальные - наследники QWidget, остальные - нет.

Нет, нельзя. Никто и не говорил что нет различий, речь шла про визуальное программирование.
[/quote]
а разве это не принципиальное различие? может быть можно написать компоненту, загружающую DFM рантайм? нет.
а то, что редакторы в некоторой степени похожи - это ещё ни о чём не говорит.

нет, не может. контейнер в принципе не может иметь визуального представления.
не станешь же ты утверждать, что QList<QPixmap> может иметь визуальное представление - это было бы глупо...
контейнер визуальных компонентов ещё не становится визуальной компонентой, т.к. не имеет возможности отрисоваться.

довольно узкий взгляд.
в дизайнере Qt всё, что можно перетащить на форму - визуальные компоненты. в то же время свойства объектов по обыкновению не являются визуальными компонентами (кроме parentWidget, которое всего лишь враппер над parent).

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

Какими мерками меряем?

Думаю по колличеству фич, Delphi, VisualStudio .NET.

м... тогда нужно Qt Creator сравнивать, а не "голый" дизайнер.

Странно, а что тогда народ из БД подгружает?

Можно. Достаточно просто. Многие так делают.

А причем тут VisualStudio .NET. к Qt Designer? Извольте объяснить

Не знаю говорил ли кто-нибудь здесь, что Qt отличается от дельфи еще и тем, что может собираться и работать на нескольких популярных компиляторах, а не только bcc? Я не говорю о кроссплатформенности, а именно о компиляторах gcc, msvc, bcc, icc. Большинство хороших бесплатных библиотек пишется на Си/Си++, а не Паскале. И только один компилятор может увязать все эти библиотеки на почти любой ОС - gcc.

Имелись в виду дизайнер Delphi, дизайнер WinForms VisualStudio.NET и Qt дизайнер.

По поводу QIcon - скажу что ты рассматривал в одном контексте, я в другом(я писал опосредованно, даже специально выделил). Про QPixmap тоже можно сказать что это массив пикселей (точек).
По поводу всего остального мы оба правы, все зависит от с какой стороны рассматривать. Я пытался просто провести аналогию между типами компонент QT дизайнера и Delphi/Builder, естественно что однозначно это сделать нельзя, можно интерпретировать и так и так.

> QPixmap тоже можно сказать что это массив пикселей (точек).
нельзя. под иксами QPixmap - это враппер над X Pixmap, который фактически используется для визуализации этих самых пикселей (рисуя на X Pixmap, мы рисуем "на экране").

хорошо. если рассматривать со стороны делфи, ты прав. поздравляю :)

О, пошли б./м. конкретные вопросы. Будем "конкретно" разбирать. :)

1. Про невизуальные компоненты.
Они хороши для быстрого прототипирования. Когда нужно за час/день нарисовать рыбу интерфейса, которую можно показать заказчику и потом выбросить.
Для нормальной разработки они плохи потому, что при их использовании логика приложения размазывается между текстом на языке и визуальном представлением формы/фрейма/датамодуля. Что существенно затрудняет понимание/рефакторинг/слияние кода. Т.е. поддержку и развитие.

Qt-ёвый дизайнер отвечает только за визуальное представление. Он позволяет редактировать и смотреть. QAction тоже относится именно к визуальному представлению.
Что позволяет чётко разделить дизайн графического представления и логику.

В DeBilder-е тоже можно разграничить, но т. к. среда не предоставляет чётких средств для этого они (представление и логика) часто смешиваются и получается неподдерживаемая каша. :)

Кроме того, для Qt существует множество биндингов для разных языков. Python, Perl, ADA, Haskell... и все они используют один дизайнер и один формат UI-шек. Это огромный плюс, но тоже накладывает свои ограничения.
Например UI-шке не получится сохранить какой-то код или ссылку на код (как для событий Delphi) т. к. не ясно с каким языком это будет использоваться и есть ли в нём нужные для разрешения этих ссылок механизмы.

Кстати, быстрого прототипирования можно добиться на Qt просто используя тот же Python - скорость разработки на нём почти на порядок выше чем на С++ или Delphi. :)

И да, DFM можно грузить в рантайме. Так что тут с UI только форматы разные.
Хотя так никто почти не делает - очень уж это заморочно и замысловато. :)

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

3. Про размеры.
Есть такая проблема. Статически собранная минимальная программа на Delphi с одной пустой формочкой 700-800 кб.
Для аналогичной проги на Qt как минимум в 2-3 раза больше.
Линекр Delphi таки сильно лучше линкера С++. Правда у него и работа попроще. :)

4. Про сигнал/слоты.
Вызов события в Delphi - это просто косвенный вызов. По сути тот же вызов виртуальной функции.
В С++ честных аналогов такого механизма нет, хотя многие распространённые компиляторы, такие как bcc, msvc, gcc имеют соответствующие расширения С++.
С другой стороны механизм сигнал/слот в Qt это гораздо больше чем события Delphi. Он позволяет привязывать несколько слотов к одному сигналу, делать синхронные и асинхронные вызовы, обрабатывать сигнал в разных потоках.
Понятно, что он при этом несколько медленнее чем косвенный вызов события Delphi.
С другой стороны, все эти механизмы - это всё же в основном отработка взаимодействия с пользователем. Для критических к скорости мест их использовать не следует. Т. е. время отработки самого вызова не критично.

Тезис про невизуальные компонены был в том, что этого нет в Qt. Спорить хорошо это или плохо я не хочу. Если это нужно для создания прототипа, то с Qt это не  возможно. А это минус.
Таже самая картина про исключения. Тезис был, что нет поддержки. Почему этого нет, то это другая история, которой наверняка есть обоснование. Но их нет, а это минус.

>>Кроме того, для Qt существует множество биндингов для разных >>языков. Python, Perl, ADA, Haskell...

Я убеждён, что в один момент времени человек разрабатывает код для одного языка. Иметь ui.xml, который будет подгружаться к разным языкам не представляется промышленным подходом к программированию. Это первое. Второе. Код обработчика не предлагается сохранять в ui.xml. Я имел ввиду вот какую возможность:
- Создать проект ui формы в Qt дизайнере.
- Связать этот проект с *.h, *.cpp файлами (для Perl с *.pl и т.д.) в которых будет реализация.
- Добавить форме пользовательский слот.
- Перейти в файл *.cpp и в нём уже будет сгенерирована функция слота, в которой я могу написать код.

так уже было и от этого дешёвого трюка уже отказались...

поддержка есть. опциональная. и это хорошо.

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

Обоснуй конкретно в чем минус того что в библиотеке нет исключений.  Кстате в самой либе исключения используются(пройдись поиском) хотя их раз два и обсчелся. Лично я считаю что отствие в библиотеки исключений явный +. Даже если не учитывать возможные проблемы в прошлом с исключениями для других компиляторов надо помнить что Qt используется для разных платформ(как по архитектуре так и по мощности). А вы до сих пор смотрите на Qt как пользователь и разработчик под Windows. Так вот у вас десктоп ПК скажем с несколькими гигагерцами и гигами оперативки и вызвать/обработать исключение для вас ничего не стоит. А как на счет встраиваемых ситсем где каждый мегагерц и каждый метр памяти на счету? Обработка исключения не такая уж и дешевая операция.

>>Я убеждён, что в один момент времени человек разрабатывает код для одного языка. Иметь ui.xml, который будет >>подгружаться к разным языкам не представляется промышленным подходом к программированию. Это первое.

Хочу тебя заверить что в крупном промышленном проэкте может участвовать несколько языков


>>Второе. Код обработчика не предлагается сохранять в ui.xml. Я имел ввиду вот какую возможность:
>>- Создать проект ui формы в Qt дизайнере.
>>- Связать этот проект с *.h, *.cpp файлами (для Perl с *.pl и т.д.) в которых будет реализация.
>>- Добавить форме пользовательский слот.
>>- Перейти в файл *.cpp и в нём уже будет сгенерирована функция слота, в которой я могу написать код.

Ты удивишся если глянеш на дизайнер для 3 QT. Правда слот там добавлялся в *.h  

Их действительно нет, но это плюс и я объяснил почему. :)

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

Файл *.ui в Qt - это всего лишь представление GUI. Он не привязан к языку.
Это представление может разрабатывать дизайнер вообще не умеющий прогать. И это вполне промышленный подход.
Кроме того, эти формы могут разделятся несколькими проектами на разных языках, чего исключительно сложно добиться в случае дебилдера (я такое делал - геммор жуткий).

Зачем это нужно дизайнеру интерфейса (человеку)?
Кроме того, в этом случае Qt дизайнере должен уметь работать со всеми языками для которых есть биндинги. Даже с теми, к которым пока этих биндингов нет. :)
Хотя никто вполне просто сделать специализированную среду под конкретный язык, которая будет именно так себя и вести.
Например почему бы не добавить это в QtCreator, VS Integrator, Eclipse plugin, Eric4?
Код то открыт. :)

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

на счёт .ui тема уже даже почти устаревшая - грядёт DUI (Declarative UI)
вот тогда возобновим тему и продолжим обсуждение/сравнение с новыми силами...
сильно сомневаюсь, чтоб багланд в ближайшие годы осилит подобное )

Минус в том я их не могу использовать, вроде 2 раза уже написал! Например, у меня есть очень большой проект, который я хочу портировать под Qt. Он завязан на исключения. Помимо другого геморроя прибавляется геморрой с обработками ошибок.
Если у вас есть проект, который часть GUI форм рисует на Perl а часть на С++ то я не ваш клиент.

Сейчас делается тоже самое, в UI_*.h файле генерируется виртуально-абстрактная функция, которой потом в наследнике ручками нужно прописать реализацию (кажется так). Вот заготовку этой реализации правильно чтобы сгенерировать дизайнер. Сравни количество шагов, которые нужно сделать, чтобы начать заполнять обработчик в дизайнере Delphi и дизайнере Qt. Как в рекламе – разработчики Велобаджи уже давно празднуют, а разработчики Велорибы пишут ручками обработчики на Qt:))

Это может активизироваться, в том числе, когда дизайнер куда-то встроен, но мета-информацию для генерации должен предоставлять дизайнер. Насчёт код открыт, я тоже посмеялся :)


У Miscrosoft такое уже давно есть – WPF/XAML. У Mozilla - XUL.

>>на счёт .ui тема уже даже почти устаревшая - грядёт DUI (Declarative UI)
Тут просто подходы связанные с разделением труда, т.е. можно такие параллели провести:

Борланд - микрософт Ворд
Qt - TeX / DocBook

Вроде тебе два раза писали что с этим проблем нет. Я напишу третий раз :). Использовал исключения в проэктах с Qt не было проблем

Да не пытайтесь вы его переубедить - это бесполезно... Когда на 1-й странице 3 человека написали что поддержка опциональная + возможность в своей программе их использовать вообще остается всегда, и все равно утверждать что их нет... я не знаю что тут...

Вообще не знаю что делать оказывается в Qt невизуальные компоненты положить на форму нельзя, исключений в упор нету, прога Hello World 100 Мб весит. С ui - шниками вообще все плохо... Зачем я только связался. Иду в магазин за Delphi - вот это действительно нормальная стабильная среда.  ::)

Лучше давай сядем за Visual Basic  ;D

О точно - ну а формочки на MFC будем рисовать ;D

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


А что смешного то? О_о

Попробуй выбросить исключение в слоте или eventFilter.
Правильно с точки зрения удобного и быстрого процесса разработки софта.
Не нашёл. Ссылку можешь скинуть?

+1

ушли от "удобного и быстрого процесса разработки софта" к неудобному и медленному...
действительно, что они там курят? :)

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

+100

+1

Не устали холиварить? :)
А сколько бы полезного кода вместо этого было бы написано!
Я абсолютно со всеми согласен. Спорить не стану. Да да да, С++ - лучший язык программирования, а Qt - лучшая библиотека для построения GUI.
Это истина. С ней не поспоришь.

п.с.
http://www.prog.org.ru/index.php?topic=9980.msg58430#msg58430

собсна, я отвечаю в паузах "на раздумье" в процессе написания полезного кода :)

мля...
я думал, это старую ветку подняли, а там (страниц на пять-семь) раньше столько смешного! завтра почитаю с утреца - подниму себе настроение :)

В DeBuildre-е и в С++ разные модели обработки исключений. :)
В С++ считается, что если исключение нигде в программе не обработалось, то программа должна умереть.
Именно это и происходит в Qt если необработанное исключение долетело до цикла сообщений оно погасит его и пролетит дальше.
При этом все ресурсы корректно освобождаются.
Кстати, если слот связан с сигналом как DirectConnection, то исключение сначало прилитит в точку возбуждения сигнала, где его можно перехватить стандартными средствами. :)

В VCL-е принята другая политика - необработанное исключение гасится в цикле сообщений.
Кстати так же ведёт себя и PyQt. :)

Да, вот что написано в исходниках Qt по этому поводу:
Так что всё в твоих руках.

Ты видимо хотел написать не разработки софта а клепария прототипов? :)

Я это читал. Поэтому сделал такие выводы насчёт исключений.
Вот ситуация, я создаю поток QThread. Но в системе закончились свободные хендлы (случай сервера). Функция CreateThread платформы не смогла создать поток. Как Qt мне сообщит об этом?
Другой пример содаю QWidget, но платформа не смогла создать окно. Как я об этом узнаю?

А что на Qt быстро разработать качественный софт нельзя?:)

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

Вполне можно. Но приёмы несколько различаются.
Ведь и топором и пилой можно запросто свалить столб, но делать при этом нужно кардинально разные движения. :)

если QThread::start не смог создать поток то isRunning вернет false. Но такая ситуация маловероятна на мой взгляд.
QWidget по-умолчанию не использует платформо-зависимые window handle, поэтому такая ситуация маловероятна. (бегло посмотрел исходники - такая ситуация корректно не обрабатывается, все что произойдет - будет выведено warning сообщение, но сложно сказать как эту ситуацию корректно обработать - если закончились хэндлы, то что-то очень серьезно пошло не так в приложение или в ОС).
т.е. я бы сказал что эти проблемы - надуманные.

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

в данный момент не все части Qt являются exception safe (например контейнеры и исключения при аллокации памяти), в будущих версиях эта часть будет улучшена.

во-первый - не так. во-вторых в Qt Creator это реализовано (если я правильно понимаю то речь о том чтобы перейти к написания кода обработчика события из ui designer, так?). в-третьих - Qt Creator это приложение с открытым исходным кодом и разработчики очень открыты для контрибуций код - милости просим, ваш патч (надлежащего качества) будет принят с удовольствием.

isRunning не атомарный флаг, поэтому определить по какой причини он сброшен представляется проблематичным.
Qt, насколько я понимаю, использует CreateWindowEx в Windows реализации и XCreateWindow в Linux для создания окон. Если это так, то возникает простая ситуация - Linux, упала сеть. Связь с X-сервером временно потеряна, окна не создаются. Хотелось бы продолжить работу без перезагрузки приложения, когда сеть поднимится. Как обработать?
Если я ни чего не путаю, в Linux можно устанавливать лимиты на колличество запущенные процессов, потоков у пользователя.
Да, правильно. Про это речь.
Видимо вы имеете отношение к разрабоке Qt, хотелось узнать каково видение развития дизайнера по части не визуальных компонент? Почему эта возможность пропала в 4.х?

Да на фиг они нужны то - хоть один реальный пример?

Если не секрет - что в его словах вас навело на мысль что человек является частью оф. команды троллей? То что креатор открытый и сама Qt не для кого не секрет... Может для вас?

Довольно странный вопрос от человека, который долго программировал в Delphi.


Человек написал - "в будущих версиях эта часть будет улучшена.". В подписи указал город Oslo. В соседней ветке разместил ссылку с вакансиями фирмы Qt.

Нет, то что QtCreator открыт для меня не секрет.

Подход "чтоб было" ведет к появлению кучу хрени, которая совсем не нужна и мусорит суть. Давайте еще сделаем так, чтобы при успешной компиляции появлялся розовый зайчик и радостно сообщал, что проект таки собрал! Чтоб было.

+100

См. книжку Дизайн и эволюция языка C++

по-умолчанию CreateWindowEx используется только для toplevel окон, все остальные виджеты не используют нативные хэндлы. подробнее (http://labs.trolltech.com/blogs/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/).

насчет X11 - если сеть упала и сессия была разорвана, то после восстановления сети протокол больше не поднимется насколько я помню. Это поведение необходимо изменять в самой реализации X-сервера.

не знаю. вероятно пропала и не появилась в Qt 4 потому что не была востребована и пользователи не присылали ни патчи ни feature request для нее.

Довольно интересно. Не знал об этом. Спасибо за информацию!

Не факт, что это не измениться в след. версии X. Если же сессия умирает совсем, как вы говорите,
то можно деинициализировать всё X-соединение и заново пытаться установить связь с X-дисплеем, если
речь идёт про стрессоусточивое приложение. Эта фраза уже даже относится не к исключениям, а относится
к механизму обработки ошибок платформы в целом. Удобно такие и другие ошибки обрабатывать исключениями. Очень жаль, что существуют платформы на которых обязана работать Qt и которые не поддерживают исключения.
Другие аргументы (overhead и т.д.) не кажутся такими существенными.

если это изменится то с большой вероятностью этот код будет в Xlib (т.е. в клиентской части, т.е. это будет прозрачно для приложения).

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

Для поддержки исключений из цикла обработки сообщений есть возможность переопределить QCoreApplication::notify() - отлично. Но если идти до конца, то нужно обеспечить возможность кидать исключения в слотах. Формально (по документации) порядок вызова слотов произвольный, т.е. это подразумевает дизайн программы, при котором в слотах находится независимая логика. Т.е. исключение в слоте не должно блокировать вызов остальных слотов данного сигнала. Для обеспечения такой возможности нужно патчить исходный код Qt, если не ошибаюсь, QObject::activate(). Делал это, когда перешел с VCL, правда потом от этого отказался - отдельный вариант QtCore не всегда удобен.

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

Это привычка к более совершенному способу обработки ошибок.

Никто не говорил, что эксепшны совершеннее ерроркодов.
В Qt можно встретить места, где класс Эррор кидается сигналом (очень удобно при асинхронной работе). Ловите эксепшны/проверяйте эрроркоды при асинхронности. Удачи:) Всё зависит от задачи.
Тотальные эксепшны раздражают (c#), если честно.

Тема избита. Не буду здесь провоцировать обсуждение данного вопроса.

Согласен. Очень удобно. Не менее удобно в таких случаях (при асинхронной работе) вместо ерроркода использовать исключения - поток завершился, проверяем результат в виде исключения.

Меня сильно раздражает, например, такое:

сори за офтоп... но по моему это вопрос религии... и холивар тыт разводить не стоит...