использование Qt может быть мотивировано лишь тогда когда GUI строится на нём

по скорости особо никакой разницы не заметно (вроде?)

QString удобнее, но не настолько

главное правило: не тащить лишних зависимостей без необходимости

> главное правило: не тащить лишних зависимостей без необходимости

Qt вроде не тащит.

использование Qt может быть мотивировано лишь тогда когда GUI строится на нём

В этом-то и главный вопрос - сейчас Qt многими позицианируется _именно_ как расширение крестов. Nokia ?

> главное правило: не тащить лишних зависимостей без необходимости

Qt вроде не тащит.

Qt и есть та лишняя зависимость :)

> использование Qt может быть мотивировано лишь тогда когда GUI строится на нём

В этом-то и главный вопрос - сейчас Qt многими позицианируется _именно_ как расширение крестов. Nokia ?

та это когда Qt головного моска у людей, «ничо» оно не шире :)

единственное что есть GUI-строилка хорошая, используешь её - используй Qt specific approach

> Qt и есть та лишняя зависимость :)

Так в том и вопрос? Может и не лишняя :)

> та это когда Qt головного моска у людей, «ничо» оно не шире :)

Так это у тебя что-то личное, говорят, Qt - спасение крестов )

> Qt и есть та лишняя зависимость :)

Так в том и вопрос? Может и не лишняя :)

хорошо, давайте с этой стороны зайдём, что Вы ожидаете от Qt?

вся функциональность которая присутствует в Qt существует и в открытом виде по разным либам

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

если есть C++ и нужен хороший GUI, то почему бы и не заюзать Qt

далее, Qt весьма динамично развивается и это хорошо, но есть и отрицательная сторона - взгляните на bugfix list'ы ихние, довольно внушительные портянки, и отдельные записи этих портянок могут серьёзно испортить настроение где-нибудь посередине проекта (у меня такое было, слава богу что update уже был доступен)

и да, я бы не рассматривал Qt именно как расщирения языка (хоть формально оно таким и является) ибо status quo С++ как языка в Qt вполне себе сохранено

говорят, Qt - спасение крестов

это очень зависит от колокольни с которой смотришь :)

лично мне в проектах часто не нужен Qt, а порой даже C++ является излишеством, как то вот так :)

с другой стороны в Qt нет практически ничего принципиально нового

а уж что там и как - каждый решает для себя

Мне Qt пригодилось, когда надо было выбрать фреймворк покруче, чтобы потом не заморачиваться с другими зависимостями. Но это был никак не unixway. Большой плюс Qt: самая лучшая документация из всех виданных мною проектов (средненькая у Boost и GLib/Gtk, самая ужасная у STL и в MSDN).

> лично мне в проектах часто не нужен Qt, а порой даже C++

Sorry, забыл, что все - именно для использования C++

:) ну вроде в этом контексте и идёт обсуждение

я просто не понимаю зачем использовать QVector, в то время как есть std::vector, который нифига не хуже, да ещё и в основных компиляторах идёт искаропки

ну и т.д.

Да, и QVector ...

foo.cc:

#include <QVector>

struct Point
{
  int x, y;

  Point(int x, int y) : x(x), y(y) { }
};

int main()
{

  QVector<Point> ps;
  ps << Point(0, 0);

}

max@neptune:~/1/
% make      
g++ -c -pipe -O2 -pipe -march=native -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -o foo.o foo.cc
In file included from /usr/include/qt4/QtCore/QVector:1,
                 from foo.cc:1:
/usr/include/qt4/QtCore/qvector.h: In member function 'void QVector<T>::realloc(int, int) [with T = Point]':
/usr/include/qt4/QtCore/qvector.h:547:   instantiated from 'void QVector<T>::append(const T&) [with T = Point]'
/usr/include/qt4/QtCore/qvector.h:285:   instantiated from 'QVector<T>& QVector<T>::operator<<(const T&) [with T = Point]'
foo.cc:14:   instantiated from here
/usr/include/qt4/QtCore/qvector.h:507: error: no matching function for call to 'Point::Point()'
foo.cc:7: note: candidates are: Point::Point(int, int)
foo.cc:4: note:                 Point::Point(const Point&)
make: *** [foo.o] Ошибка 1

Вот зачем QVector хочет чтобы у его элементов был конструктор по умолчанию? Какой смысл операции push_back требовать наличия конструктора по умолчанию?

> я просто не понимаю зачем использовать QVector, в то время как есть std::vector

Так вопрос то в этом. Я ж не утверждаю, а спрашиваю :)

Но вот, например, для string перевод string <-> number, нужен костыль -
boost (lexical_cast), а QString - OK...

Так очевидно же, исправить глюки плюсов. Не ?

Кстати, вопрос почти в тему: существуют ли реально консольные приложения на Qt? Посмотрел бы ради любопытства.

xmlpatterns :-)

Но вот, например, для string перевод string <-> number, нужен костыль - boost (lexical_cast), а QString - OK...

lexical_cast - не костыль, хотя бы потому что может расширяться для поддержки новых типов, в отличие от интерфейса QString

Так очевидно же, исправить глюки плюсов. Не ?

Какой глюк плюсов исправляет требование наличия конструктора по умолчанию операцией QVector::push_back?

> Какой глюк плюсов исправляет требование наличия конструктора по умолчанию операцией QVector::push_back?

Ну эт я повелся на <Begemoth> см. выше.

QVector::push_back?

Ну так и хотелось узнать - QVector vs Vector - сказать можно что ?

Тема

Как я понял:

Приверженцы с «Q» и «без»

поподробнее...

Qt имеет только один недостаток: у человека, использующего его, может возникнуть иллюзия, что он знает C++.

Ну так и хотелось узнать - QVector vs Vector - сказать можно что ?

Базовое существенное отличие - QVector реализует политику copy-on-write, это документированная особенность и на неё можно полагаться в программах. std::vector такого не гарантирует. В добавок в документации Qt указывается какие операции являются потоко-безопасными, в отличие от STL, т.к. пока в стандарте ничего вообще не сказано о потоках.

Ещё QVector предоставляет Java-style итераторы.

Ну и отличие связанные с использованием с другими частями Qt - исполбзование в сигнлах/слотах, QVariant, сериализации без лишних телодвижений.

> Qt имеет только один недостаток: у человека, использующего его, может возникнуть иллюзия, что он знает C++.

Значит QPthread - _точно_??? лучше boost::thread ???? ( и _т.д._ важно)

Ессно QThreat

> Значит QPthread - _точно_??? лучше boost::thread ???? ( и _т.д._ важно)

Если говорить о том, как все это работает, то разницы нет. Если говорить об API, то Qt однозначно лучше.

QThread, лол ))

>главное правило: не тащить лишних зависимостей без необходимости

вообще можно типа как пользоваться только qtcore, без qtgui и всех остальных модулей

Значит QPthread - _точно_??? лучше boost::thread ???? ( и _т.д._ важно)

Здесь нужно учитывать, что QtCore - это ещё и сигналы/слоты, которые прозрачно работают между потоками.

>Qt имеет только один недостаток: у человека, использующего его, может возникнуть иллюзия, что он знает C++.

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

>вообще можно типа как пользоваться только qtcore, без qtgui и всех остальных модулей

да, но в большинстве дистрибутивах qtcore нельзя установить без qtgui.

> Qt - это дельфи нового формата

Ты так говоришь, как будто это плохо

ты про убогие rpm-based?

>Но вот, например, для string перевод string <-> number, нужен костыль - boost (lexical_cast), а QString - OK...

Использование *_cast<тип>(чтонадо) для приведения чегонадо к типу - это костыль? Скорее уж QString - костыль.

В c++ типизация, конечно, не самая строгая на свете, но он старается.

>Здесь нужно учитывать, что QtCore - это ещё и сигналы/слоты, которые прозрачно работают между потоками.

Код слотов выполняется в потоке, сгенерившем сигнал. Если в потоке 1 создаётся struct A { public slot: X() { sleep(60); } }; и некий поток 2 дёргает этот слот своим сигналом, то спать минуту будет поток 2. Почему-то не все это понимают.

Моё мнение - без Qt кодить на C++ не то чтобы не реально, это как сейчас сидеть под никсами юзая только links и vi.
На голом STL уже мало кто кодит. По сему сразу понятно.
Буст это такой ужастик для профи в плюсах, которые никогда его не юзали, но считают что всё понимают в темплейтах.
Я отказался от буста из-за его офигенной сложности(внутри), из-за которой некоторые моменты приходится самому гадать. Ну и, конечно, ошибки, что он даёт. Круто, конечно, юзать буст, но вот напишешь строк 200 кода и он тебе выдаст дысячи 2 печатных строк ошибок и всё... Думай сам что делать. Мне приходилось комментить куски кода по 10-50 строк кода и вылавливать ошибки.
Однако Qt имеет свой препроцессор для своих фич(qmake), т.е. в нём предусмотрен отлов ошибок в его прибамбасах.
Если важна скорость, то лучше буст, конечно. Однако и Qt не слаб. Отстаёт не значительно, да и то только в некоторых моментах.

Умный каст это не костыль. А вот обёртка ручного каста для ручного каста - костыль, а точнее - велосипед.

Пришли суровые cpp-тролли...
Вот едят кактус, плакают, плюются от горечи, но едят и всем советуют.

> Qt - это дельфи нового формата

Делфи славилась своими чудо-компонентами и мышкокодингом. Так что в лужу.

Ну хотя бы.. А в deb-based разве не так? В убунте qt разделена на несколько пакетов?

Я не с++ тролль, ты меня с кем-то перепутал.

Что значит «чудо компоненты»? А мышевозность есть в QtCreator.

Дык я не про тебя, а вообще >:)

В QtCreator нет её, зато есть в QtDesigner.
Делфи славится своим паскалем(тем что это объектный паскаль, по сути) и тем что у него большой дизайнер для окошечек с тучей контроллов, а так-же большое быдлокоммьюнити, в котором можно искать куски кода и сразу их копипастить, при этом обращаясь на ЛОРы из-за ошибок вроде необъявленных переменных, лол.

Код слотов выполняется в потоке, сгенерившем сигнал. Если в потоке 1 создаётся struct A { public slot: X() { sleep(60); } }; и некий поток 2 дёргает этот слот своим сигналом, то спать минуту будет поток 2.

man QObject::connect на предмет 5-го параметра type.

Почему-то не все это понимают.

Почему-то не все читают документацию.

> Что значит «чудо компоненты»?

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

> Вот зачем QVector хочет чтобы у его элементов был конструктор по умолчанию?

для resize()

$ dpkg -l|grep libqt4 | awk '{ print $2}'
libqt4-assistant
libqt4-core
libqt4-dbus
libqt4-designer
libqt4-dev
libqt4-gui
libqt4-help
libqt4-network
libqt4-opengl
libqt4-opengl-dev
libqt4-qt3support
libqt4-script
libqt4-scripttools
libqt4-sql
libqt4-sql-mysql
libqt4-sql-sqlite
libqt4-svg
libqt4-test
libqt4-webkit
libqt4-xml
libqt4-xmlpatterns

для resize()

resize для push_back не нужен.

нужен. resize = realloc.
может предложите троллям лучшее решение для резервации места под объект?

> Код слотов выполняется в потоке, сгенерившем сигнал.

Борис, ты не прав. Это зависит от того, в каком потоке находится event loop, к которому прикреплен объект.

Потому что Qt написана человеками для человеков, а буст написан упоротыми плюсоёбами для самих себя.