qt

[metaclass]

Наконец, вместо того, чтобы копировать qt с компа на комп и копаться в его исходниках, немного побаловался с написанием программ. Выводы:
1) qt creator (и возможно, сам qt) еще таки дорабатывать и дорабатывать. Глючит-с. Мне кажется, что это не уровень RC, это таки сырая бета.
2) qt не использует стандартных виндовских контролов вообще, судя по тому, что spyxx не видит ничего в проге кроме топ-левел окна.
3) Способ разработки гуя достаточно интересен, некоторые вещи интуитивно понятнее и удобнее дельфей и вижуал-студии.
4) Надо написать хотя бы одну полноценную прогу на этом деле, чтобы таки осознать, стоит дергаться ради галочки "можно писать кроссплатформенный GUI".

Comments

[max-posedon.livejournal.com]

1) qt creator да глючный, сам qt-rc много стабильнее даже предыдущего стабильног qt
2) Тут немного истории, Qt раньше очень даже их использывал/мог использывать, но по причинам performance они таки написали свой (это главная фича qt-4.5), наскока я знаю она опциональная, но выключенная по умолчанию
3) Там чем дальше, тем вкуснее :)
4) Good luck!

[max-posedon.livejournal.com]

P.S. Надо наш production app на 4.5rc1 обновить, лично посмотреть, что вкусно/сломано в 4.5rc1

[thesz.livejournal.com]

Я не спец, но, говорят, стоит.

Коллеги написали какой-то развесистый редактор схем нестандартной БД за небольшое время. Очень довольны по сию пору.

[theiced.livejournal.com]

1. qt creator не видел, но qt он таки rock stable последние лет 7-8,
2. таки макс начал аписнять но недообъяснил - у них там одно опенглное окно в котором всё рендерится как я слышал. и вам таки не пофиг как оно там? выглядит так же? да. ведёт себя так же? да.
3. ви таки ещё не оценили все прелести лэйаутов.
4. надо.

[theiced.livejournal.com]

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

[zamotivator.livejournal.com]

Ну, первую дозу принял, дальше подсядешь =)
З.Ы. это реальный пиздец - я не могу всерьёз ни одну библиотеку GUI рассматривать, после опыта разработки на Qt =) Блевать тянет что с gtk, что с winapi, что с wxwidgets =)

Но у Qt есть недостатки. Но у кого их нет =)

[kiryl.livejournal.com]

Главный недостаток Qt -- это C++.

[metaclass.livejournal.com]

Почему это недостаток и какие альтернативы?

[kiryl.livejournal.com]

http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 - Тут Линус хорошо описал.

[max-posedon.livejournal.com]

Не путайте тёплое с мягким, там не перечислино ни одного недостака C++, кроме того, что на C++ пишут больше идиотов чем на C, не более.

А трэд конечно эпичный и весёлый, и как раз из его следуют, что C++Qt ОЧЕНЬ хорош, ибо ребята сфокусирывались на архитектуре и на API, а не на синтаксическом сахаре.

[metaclass.livejournal.com]

А, это известная печаль, про неадекватность объектных моделей. Это обсуждение периодически всплывает, начинается холивар, ни к чему толковому не приходят и все заканчивается при своих:)
Вот еще на эту же тему.

[kiryl.livejournal.com]

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

[max-posedon.livejournal.com]

Пробовал, вполне успешно, gсс в этом плане весьма объективен.

А во вторых, Qt никакого отношения к STL не имеет фактически, он написан на "без шаблонном" C++, так что, камень в сторону STL, совершенно мимо Qt.

[kiryl.livejournal.com]

Если вы пишете программу на C++, как заметил Линус, рано или поздно, кто-нибудь решит, что использовать STL или Boost -- это хорошо и тут начнутся пляски.

[max-posedon.livejournal.com]

Ну зачем же вы троллите? Qt уже >10 лет, там нет ни STL ни Boost. Давайте обсуждать ваш тезис "Qt плох потому что C++", а не "C++ плохой, потому что в нём есть STL и Boost" учитывая что в Qt их нет.

[kiryl.livejournal.com]

Вот это читали - http://www.nothings.org/computer/cpp.html ?

[max-posedon.livejournal.com]

Вы СНОВА о C++, может хватит уже?

Ничего! из ваших ссылок не характеризует то "подмножество" C++ на котором пишут на Qt, и на котором написано Qt.
Trolltech вкурсе многих проблем C++, именно поэтому там появился moc (по сути костыль - по факту отличное решение), ну нет в C++Qt всех этих проблем, нету.

[zamotivator.livejournal.com]

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

[kiryl.livejournal.com]

От всех извращений C++ они избавится всё равно не смогут.
От потери производительности на ровном месте. Например, длиннющие имена символов. Динамическому линковщику приходится перелопачивать дикие объймы данных, только что бы сделать все relocations. Дриппер считал сколько строк нужно сравнить динамическому линковщику для запуска OpenOffice 1.0. Получилось порядка 18.5 мегабайт!
Это этого Qt никуда не деться.

[kiryl.livejournal.com]

Для производительности придумали C.

[max-posedon.livejournal.com]

1. запуск app != производительность app
2. решения этой проблемы нет нигде, вы можете написать подобный API на C, тока в нём всё равно будут длиннющие имена, тупо потому что методов *много*
3. медленный старт openoffice-а был обусловлен совершенно другой бедой, а не кол-вом библиотек с котороыми ему надо было слинковаться
4. 20Mb это совсем немного

[max-posedon.livejournal.com]

Увы, Qt работает быстрее gtk, и быстрее gtk+cairo.

[kiryl.livejournal.com]

1. Я в курсе. Это всего лишь пример. Можно ещё вспомнить про таблицы виртуальных методов.
2. libgtk-x11-2.0.so -- средняя длинна символа 25.2. libQtGui.so.4 - 35.9. К тому же в случае C, strcmp, как правило, обнаруживает неравенство раньше ибо в символах нет неймспэйсов и имён классов.
3. Мы тут не OO обсуждаем.
4. Ну-ну.

[kiryl.livejournal.com]

Пруфлинк?

[max-posedon.livejournal.com]

2. статистика это 3й вид лжи, и кстати это снова о старте app. И ещё, сигнатуры C и C++ начинаются с типов на моей памяти, namespace-ы врятли причём к strcmp в таком случае