Тем кто не любит Qt.

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

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

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

Конечно мечты. Ибо это требует интерскопии объекта

Да что у вас за мода, порезать все и вся вокруг?
Может быть человеку на самом деле это важно и он не может определится. Я тоже в свое время был в подобной ситуации.

1. Нельзя копировать QObject, из-за этого обилие указателей в библиотеках Qt и коде, написанных с его помощью. 2. Сигнатуры сигналов проверяются в рантайме. Тут есть недостатки, но есть и достоинства. Хотелось бы всё-таки сигналы на шаблонах.

Это ненавязчивое предложение грохнуть тему?

P.S. Вот моя тема некоторой давности практически про то же.
Там первые несколько сраниц вполне себе оп теме: http://www.linux.org.ru/forum/development/4088836

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

и что-нибудь из функциональщины.

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

> А вообще Qt хорош и замечателен. Если чего-то и не хватает, так это автоматической сериализации. Но это мечты... (Хотя, возможно, я просто плохо почитал документацию).

QDataStream, не?

> Нельзя копировать QObject, из-за этого обилие указателей в библиотеках Qt и коде

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

Хотелось бы всё-таки сигналы на шаблонах.

Ну не. Такого не надо

хочу полноценный ORM в Qt

Гуйню удобней писать на скриптовых языках (типа Питона), а в качестве платформы общего назначения Qt - не самый лучший выбор, ибо C++. Уметь клепать на Qt - полезно, но зацикливаться на нём точно не стоит.

Знакомься со всем подряд :)

нехватает виртуальной машины и GC. Ах да, и рефлексии человеческой, QMetaObject убог.

Так модерируй, модератор. Запарили уже устраивать тролксы в девелопменте. Хотите звезд - пишите новости.

...

Апи жирнющ плюс море всего и вся. Я был бы рад, если Qt умел лишь удобно рисовать няшные окошечки.

D-pointer'ы применены не всегда к месту.

>C++
PyQt, не?

Для этого есть Gtk, не?

> Qй-ли. Назовите хоть один тип, для которого можно было бы применить копирование

Любой, отнаследованный от QObject.

Ну не. Такого не надо

Почему? Неужели не хочется проверять типы в рантайме, а если хочется убедиться, что сигнал правильно соединён, писать тесты, которые покрывают весь код, где есть QObject::connect?

>нехватает виртуальной машины

Для таких как вы придумали яву и дотнет с моно.

Мне не понравилось на нем программировать - многословно очень, что ли. И окошки не няшными получаются.

Впрочем на работе я отказался гуи колбасить, и это совсем не мой фан, так что сейчас уже пофиг:).

> Любой, отнаследованный от QObject.

Да ладно. QWidget хотя бы не должен копироваться

Неужели не хочется проверять типы в рантайме, а если хочется убедиться, что сигнал правильно соединён, писать тесты, которые покрывают весь код, где есть QObject::connect?

Хочется. Но и хочется не знать детальную информацию о типе объекта, к которому цепляешься

>Вопрос встал в связи с тем, что я еще не совсем программист (2 курс)

Видишь ли, я мог бы тебе аргументированно объяснить, почему Qt говно, и почему ее хваленая документация по уровню даже хуже gtk'шной (спасают только examples с исходниками, но qt-demo гораздо более убого, чем gtk-demo, потому что за исходниками надо лезть в assistant), но ты этого не поймешь. Это все равно что рассказывать годовалому малышу о половом размножении человека.

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

отвратительный интерфейс с хорошей реализацией. главный минус - то, что Qt это каркас на расширенном C++: система событий прибита гвоздями, биндинги пишутся долго и мучительно (что кроме PyQt реально работает?), нормально пользоваться можно только в связке с C++ (и то - с ограничениями, накладываемыми MOC)

у того же Tk (в контексте GUI) ситуация обратная: хороший C API, бездна биндингов, библиотека легко эмбеддится в проект - но при этом хреновая реализация свистелок

> Просто поверь на слово, от Qt балдеют вчерашние MFC'шники.

Просто поверь. GTK делали выходцы из мира ассемблера и С. Так чтоб выбора нет

> Да ладно. QWidget хотя бы не должен копироваться

Не должен. Но непонятно, почему нельзя скопировать QBuffer. Непонятно, почему если я хочу заюзать интроспекцию (например Q_PROPERTY), а сразу теряю возможность копировать объект, потому что он должен быть QObject.

Но и хочется не знать детальную информацию о типе объекта, к которому цепляешься

Как минимум необходимо знать, что данный объект содержит нужный слот. Поэтому совсем без информации о типе не получится. Если хочется использовать разные классы, можно отнаследовать их от класса с нужными слотами.

Всё плохо с исключениями. Многие вещи на шаблонах смотрелись бы роднее.

>Видишь ли, я мог бы тебе аргументированно объяснить, почему Qt говно, и почему ее хваленая документация по уровню даже хуже gtk'шной <...>, но ты этого не поймешь. Это все равно что рассказывать годовалому малышу о половом размножении человека.

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

А когда gcc перепишут С++ ?)
С++ вторичен в Linux, это уже вопрос истории и здравого смысла.

> перепишут С++

fix: перепишут на С++

>перепишут на С++
http://www.linux.org.ru/news/gnu/4949755

И ?

> Но непонятно, почему нельзя скопировать QBuffer.

А почему должны? Он ведет себя как значение.

Если хочется использовать разные классы, можно отнаследовать их от класса с нужными слотами.

Палка с 2мя концами

сейчас практически все пишу на С++ с использованием Qt [..] просьба в этом треде аргументированно указать его основные (с вашей точки зрения) недостатки

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

> А почему должны? Он ведет себя как значение

В С++ есть синтезируемый конструктор копирования. Его выкидывание сужает область использования. Для этого есть какие-то основания?

Палка с 2мя концами

Расскажите про 2-й конец. Хочется узнать, чем так плохо знать информацию о типе (даже части типа).

И что там по поводу Q_PROPERTY и невозможности копирования?

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

вот и начните с того что дайте себе по шапке, ТС задал нормальный вопрос

Если касательно гуйни - tk

плюсы - стабильность, обратная совместимость, есть привязки к стопицоттыще языков, малотребовательность к ресурсам

>Просто поверь. GTK делали выходцы из мира ассемблера и С. Так чтоб выбора нет

Я считаю, тактодрочер по-любому лучше, чем MFC-ненатурал.

> умный человек сам найдет ответы на такие вопросы, а троллям нужно давать по шапке.

при таком раскладе весь лор надо порезать, ибо 99.9% лора суть баян. останутся только стишки в толксах, да.

> что кроме PyQt реально работает?

jambi?

биндинги пишутся долго и мучительно

Это проблема Qt? Это вообще-то проблема крестов. http://en.wikipedia.org/wiki/Qt_(framework) посмотри на табличку биндингов.

> В С++ есть синтезируемый конструктор копирования. Его выкидывание сужает область использования. Для этого есть какие-то основания?

Копируются значения. А не поведение.

Скопировать окно? Скопировать потоковый буфер ввода/вывода? Что еще хотите копировать и куда?

И что там по поводу Q_PROPERTY и невозможности копирования?

Об этом не думал. Тут особых причин не вижу. Все видать упирается в QObject

>Не троллинга ради, на самом деле интересно, чем не устраивает документация по Qt

Своей непонятностью. В большинстве своем это унылое доксигеновское говно со всеми вытекающими, а именно: написано косноязычными программистами и максимально сжато. К примеру, в разделе о ListView ни одна тварь не сознается, почему этот view молча игнорирует все столбцы, кроме первого. И только наследственный MFCшник знает, что multicolumn list view — это на самом деле TreeView.

почему Qt такой плохой фреймворк для С++

Потому что он «вещь в себе», при этом очень большая, но крайне ограниченная. По пунктам:

1. «Вещь в себе» — отсутствует интеграция с внешним миром и другими библиотеками. Даже контейнеры свои собственные зачем-то написали, хотя и клянутся, что это жизненно необходимо было. В 1996-м году — да, на embedded платформах — возможно. В 2010 году их Q* говно нахрен никому не нужно.

2. Qt монструозно. Огромная библиотека, в которой есть и работа с сетью, и парсер XML, и GUI, и потоки и еще дохрена всего (даже компонент браузера). Напоминаю: чем сложнее интсрумент, тем сложнее его использовать.

3. Ограниченность Qt. При всем огромном наборе классов, на всех на них лежит штамп «designed to use with Q* in Q* cases». Стоит чуть отойти в сторону от того, как по мнению разработчиков надо было использовать этот класс — и все, приехали. Велкам ту недокументированные грабли.

> Напоминаю: чем сложнее интсрумент, тем сложнее его использовать.

У.. cocao от Apple совсем сложный тогда. Там столько компонентов.

Стоит чуть отойти в сторону от того, как по мнению разработчиков надо было использовать этот класс — и все, приехали.

А где не так?

[qoute]Своей непонятностью. В большинстве своем это унылое доксигеновское говно со всеми вытекающими, а именно: написано косноязычными программистами и максимально сжато.[/qoute]
Бредишь? Или предпочитаешь маркетоидный бред для маркетологов?

И только наследственный MFCшник знает, что multicolumn list view — это на самом деле TreeView.

Вообще-то QTableView, что вобщем-то логично.

>А где не так?

В нормальных библиотеках. В boost, например.

>Или предпочитаешь маркетоидный бред для маркетологов?

info libc прояснит тебе, что именно я предпочитаю. А также man'ы из 2-го и 7-го разделов. Это образец для написания документации.

Doxygen'овское говно — это бред сивой кобылы, а не документация. И так не один я считаю, кстати. Досадно, что это говно по каким-то причинам прижилось.

у него нет C API (я программирую на C) GTK не имеет этого недостатка.

ой. он с qt плохо скрещивается иногда. в нем проблемы

Нука, покажи мне по ООП документацию такую