Почему вы используете/не используете Qt (windows-платформа)

[xokc]

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

[lit-uriy]

>>Обобщу: если надо очень скоро написать приложение, то лучше все же использовать то, чем владеешь.
Это всяко, даже если инструмент совсем убогий, но его возможности хорошо известны, равно как и методы работы с ним. Будь то хоть поганый, но прошедший медные трубы, паяльник.

[Wlad_C]

Лично мне многое нравится в Qt, но есть один тормозящий меня момент: не очень развитый набор именно готовых GUI виджетов и компонентов, поэтому в большинстве своем приходится писать велосипед

Ну это Вы не в курсе. Для Qt существует довольно много готовых виджетов, например:
wwWidget на http://www.wysota.eu.org/wwwidgets/
для построения графиков – Qwt Widgets и т.д. Погуглите. Внимательно почитайте этот форум. Найдете очень много интересного.

[Wlad_C]

Добавлю.
Привычка - вторая натура! Просто Вы еще мыслите категориями Билдера. Со временем это пройдет! Хотя, лично у меня, при переходе с Билдера (8 лет просидел) на Qt ощущения, что не хватает компонент не было. А совсем даже наоборот . В билдере для работы с юникодом приходилось использовать компоненты сторонних разработчиков (что не есть гут). QString изначально есть юникод. Чтобы избавится от "казенного" вида Билдеровских форм, опять же приходилось использовать компоненты сторонних разработчиков (платные, без исходных кодов). Виджеты в Qt изначально имеют элегантный вид, а если хочется что-то изменить для этого есть стили: легко и просто. И много чего еще нашел. То есть, в Qt я сразу нашел то, чего мне не хватало в Билдере. Поэтому, "в переходный период" у меня не было никаких сомнений. Я с энтузиазмом разбирался в Qt. Знал, что это того стоит. Не зря будет потрачено время.

[gogi]

Просто лично для себя я сделал вывод: если надо очень скоро написать приложение под win, то лучше все же использовать "старый-добрый" Delphi (Builder) с его(их) кучей "готовых" решений...

И никто не упомянул про паршивый(по качеству сгенерированного кода) компилятор в delphi/c++ builder. С Qt можно взять ms c++/intel c++ compiler/g++/... и программа будет просто банально работать быстрее.

[alexman]

Просто лично для себя я сделал вывод: если надо очень скоро написать приложение под win, то лучше все же использовать "старый-добрый" Delphi (Builder) с его(их) кучей "готовых" решений...

И никто не упомянул про паршивый(по качеству сгенерированного кода) компилятор в delphi/c++ builder. С Qt можно взять ms c++/intel c++ compiler/g++/... и программа будет просто банально работать быстрее.

Такое подозрение, что на Delphi никто толком и не сидел с этого форума.

[Пантер]

Такое подозрение, что на Delphi никто толком и не сидел с этого форума.

Было дело когда-то давно.... Компилится в разы быстрее, чем с++.

[lit-uriy]

>>про паршивый(по качеству сгенерированного кода) компилятор в delphi/c++ builder
в чём то проявляется?

[lit-uriy]

>>Компилится в разы быстрее, чем с++.
да и код компактнее и работает быстрее.
В этом отношении Дельфя никто не смог догнать

[LisandreL]

и работает быстрее

Вот в этом у меня сильные сомнения.

[lit-uriy]

>>Вот в этом у меня сильные сомнения.
а у меня нет. Это просто факт по моему (и многих других людей) опыту работы с Дельфи и другими инструментами создания ПО.

[Wlad_C]

Компилятор + библиотека + IDE - определяются кругом задач, которые с их помощью необходимо решать. Когда имеющиеся программные средства не позволяют эффективно решать поставленные задачи, подыскиваются новые компоненты, позволяющие это делать. При этом всегда приходится чем-то жертвовать (не являющемся принципиальным для решаемых задач), т.к. нет ничего идеального.
Если имеющиеся программные средства позволяют успешно решать круг нужных задач, то переход на новые библиотеки, IDE, компилятор, ничего, кроме головной боли не дает! Отсюда и возникают вопросы: почему вы используете Qt, почему вы используете Делфи и т.д.

[LisandreL]

Это просто факт по моему (и многих других людей) опыту работы с Дельфи и другими инструментами создания ПО.

У «многих других людей» факты другие:
http://www.gamedev.ru/flame/forum/?id=78283
http://www.gamedev.ru/flame/forum/?id=14391

[kuzulis]

и работает быстрее

Вот в этом у меня сильные сомнения.

Люто плюсую. Также имею сомнения.

[offtop]
Исходя из анализа работы BC 3.x - BC 5.x , эти компиляторы компилят ужасно тормозной и большой код , по крайней мере под DOS.
Просто я щас пишу одну софтинку для железки на которой установлен ROM DOS.
И для разработки программ для нее производители рекомендуют BC/TC v 3.x, так вот, если приложение сложное и необходимо фиксировать события с точностью порядка 0.1 мс, то оно просто не влезает на флэш диск девайса и работает оч. медленно.

Другое дело - компилер Open Watcom, перешел на него и ни сколько не жалею: скорость выросла раза в х3, а размер приложения упал в х5 раз.
Такие вот дела.
[/offtop]

[gogi]

>>Компилится в разы быстрее, чем с++.
да и код компактнее и работает быстрее.
В этом отношении Дельфя никто не смог догнать

В системе есть библиотеки (libc,libstdc++)/crt, написанные на c/c++. Через них ОС предоставляет прикладное API. Голая программа на с++ обязательно использует эти библиотеки. Голая программа на паскале также использует эти библиотеки, но плюс к этому использует также runtime паскаля, который представляет из себя оболочку на сишным runtime+расширения паскаля. Отсюда простой вывод, что голая программа на паскале всегда будет больше "тянуть" чем аналогичная на c++. Тянуть - имеется ввиду с динамическими зависимостями. Плюс ко всему некоторые вызовы к системе на паскале будут делаться не напрямую, а через паскалевские оболочки. Отсюда накладные расходы. Если уж сравнивать размеры бинарников, то надо сравнивать статически-откомпилированные. Тормозить или не тормозить схожие программы могут из-за библиотек(vlc/qt).

Дельфи лет 8 палочкой не тыкал, но как он может быть быстрее, если до сих пор трудности с x86_64(уже добавили или по-прежнему обещают?). То же самое относительно всяких sse/avx. Но даже если не брать все эти новые инструкции, мне очевидно, что компиляторы c++ сейчас развиваются гораздо быстрее чем паскалевские и по всяким оптимизациям уже ушли далеко вперёд.