Russian Qt Forum

Щас чего-то многие на пятый Qt перешли - нужно оно или нет? Какие преимущества, недостатки?

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

PS а так то новое в массы :D

Баги правятся, фичи реализуются  :) Чтобы не натыкаться на новые баги ждите версий 5.x.2.
Новый синтаксис signal/slot, с проверкой на стадии компиляции.
Если у вас приложение на виджетах, они мало развиваются, но немного есть развитие.

Мне наоборот интересно, почему люди держаться за Qt4? Понятно, что часто это требование начальства, но интересны аргументы? Слишком большое и сложное приложение, что уже нет смысла портировать на Qt5?

Много мелких бонусов, связанных с поддержкой C++ 0x. Довольно часто встречаю в help на используемые методы: "This function was introduced in Qt 5.x".

Я б сравнивал как
Qt 4.* - Крестьянская лошадка, неприхотливая, маленькая, тягает плуг и ничего особо не требует.
Qt 5.* - Ухоженный конь на выгул, умеет ходить боком, задом, галопом, рысью, перепрыгивать через барьеры, умеет пользоваться смартфонами, тягает плуг :)

Мой случай: 4.7 еще поддерживает Carbon, а 5 уже нет. А избавиться от Carbon - не один месяц работы (этим сейчас и занимаюсь). Ну конечно если таких завязок нет - то просто "чем новее - тем лучше".

Так вопрос вообще не стоит. Если есть возможность переходить - надо переходить. Иначе почувствуете себя отстающим, и чем дальше - тем больше.

Напр возникла проблема, наверное баг в Qt. Но на старой версии трудно найти решение, мало шансов на форуме и писать репорт бесполезно - старье уже никого не интересует. Решать самому, варианты

- как-то залатать/обойти, возможно потратив неск дней
- перейти на новую версию где это уже пофиксили

Последний выглядит как-то поприятнее  :)

почему, кстати, 4.7, а не 4.8? ;)

Тут, Igors, ситуация наоборот. На Qt 4.7 проще найти решение, чем на Qt 5 :D Инфы гораздо больше в интернете :)

4.7 потому, что в 4.8 первых версиях летало всё. Ну лично когда я пробовал 4.8 у меня были и вылеты в рабочих проектах и сбросы стилей и прочая. Потом конечно это всё доработали, но впечатление осталось :D

Сомнительная вещь, да и область применения очень узкая - когда сигнатуры сигналов/слотов совпадают 1:1 и нет перекрытых сигналов/слотов.

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

А вот более простой проект, без потоков, нормально работал :D

Это "было так" - но сейчас это уже не так. И перестроиться, признать это довольно трудно. Но упорствование совершенно бесперспективно  :)

Решения проблем для 4.7 описаны. Для пятерки все отписываются в баг трекер :D

У меня вот такое меню выскакивает, из этого я сделал вывод, что 4.7 и 4.8 примерно одно и то же.

Ну вот к примеру недостаток: в пятёрке больше dll тащить с собой надо, чтобы самый простой exe-шник заработал. Ещё недостаток: 4.7 устанавливается простым запуском установочного файла, в пятёрке вроде вручную нада что-то колдовать...

Впервые слышу :)
С офф. сайта для винды установщик Qt5 и Qt поставит, и Qt Creator вместе с компилятором.

чушь несешь в обоих пунктах (кроме длл)

Обойти оба случая можно, просто будет не очень красиво.
Перегруженные сигналы.

C++ (Qt)
connect(ui->spinBox, static_cast<void(QDoubleSpinBox::*)(double)>(&QDoubleSpinBox::valueChanged), this, &MySuperClass::setFactor);
 

Несовпадение сигнатур.

C++ (Qt)
connect(ui->comboBox, &QComboBox::currentTextChanged, [this](const QString & text) { updateText(); });
 

Зато преимущества нового подхода очевидны - не нужно проверять на работоспособность каждое соединение сигнал/слот в приложении.

В пятерке пофиксили визуальный баг с квадратной дыркой в скролле под Win8, только ради этого уже можно перейти  ;D

Шустрее работает. Когда скорость важна, а приложению не нужны печеньки, то я и от 4.2.1 не откажусь.
Меньше вес, шустрее ворочается.
Хотя надо смотреть, что там требуется.

Ну вот как раз с разницей в скорости можно поспорить. Если не сравнивать Quick в Qt4 и Qt5, то в остальном там мало что изменилось. Просто была проведена работа по разделению Qt4 на большее количество модулей. Во всяком случае это совсем не такая разница, как между Qt3 и Qt4.

Более того, если нужна консольная утилита, например, для обработки картинок, то теперь можно не тащить за собой весь GUI с виджетами как в четверке.

Я считаю что всё это держание за Qt4 ретроградством если нет реальных проблем с переходом на Qt5.

А зачем для консоли для обработки картинок тянуть с собой всё UI? Отродясь такого в Qt не видывал, тем более в 4 :D

имхо, это одно из основных достоинств пятерки. Из, может быть, неочевидного - повышенная сторогость дизайна: пусть вы имеете указатель на констант. объект: const AnObject* obj, тогда в старой реализации вы все равно можете подписаться на любой сигнал данного объекта, потому что MOC кладет на константность, а в новой реализации - нет, только константные сигналы вам доступны.

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

Ну или чего то я в этой жизни не понимаю.

Bepec
Во-первых, сигналы неконcтантны (зачем кидать сигнал из конст метода?)

Akon
Во-вторах, QObject::connect всегда принимает константный указатель на объект (так как сам connect не меняет видимое состояние объекта)

Сигнал же не изменяет состояние своего объекта , следовательно является константным.

Откуда не кинешь сигнал, он не изменит состояния объекта. Следовательно изменить какие либо данные в объекте не может.
"Константный метод гарантирует, что мы не изменим состояние класса в процессе его работы." ©

Это как-то противоречит моей мысли?

Вот пара функций из QVector:

Если эту логику экстраполировать на сигналы, то было бы как-то так:

Нет, на самом деле не гарантирует.. (и не класса, а объекта)

C++ (Qt)
struct object
{
    void some_method() const {  ++val; }
    mutable int val;
};
 

Вы сейчас хитросмудрили, а я говорю про общий случай, а не частный.

Сигнал - это уведомление об ИЗМЕНЕНИИ видимого состояния объекта. Т.е. он ВСЕГДА зовется из не-конст ф-ии. При этом, в слоте, законнекченном на сигнал, мы можем поменять sender()'a. Я уж молчу что сигнал - это вызов QMetaObject::activate(QObject *sender...) к-ый принимает неконстантный this.


Простите, ШТО? const T &   QVector<T>::operator[] ( int i ) const не меняет объект, какой нафиг itemChanged?

Сигнал САМ ПО СЕБЕ  ничего изменить в объекте не может. Вот тупо не может.
Он не может изменить объект класса никак, никоим образом. А откуда его вызывать значения не имеет.

Приведите мне пример изменение объекта класса при помощи сигнала (только сигнала) :)


PS
Сигнал это метод не изменяющий видимого состояния объекта. А кем и когда он зовётся, не имеет значения. Сигнал НЕ МОЖЕТ изменить объект, повторюсь. Он лишь извещает о чем либо с какими либо аргументами. А вот уже в слоте можно и получить объект класса и изменить, но СЛОТ это не СИГНАЛ :)

Это касается только тех данных что Вы сами объявили/видите. А внутренняя начинка QObject может меняться. Напр 2 нитки вызвали один слот с DirectConnection - будет выполнен сначала один, потом второй (но не оба вместе). Внутренний мутекс был захвачен/освобожден. 

Вы не поняли мою мысль. Пусть в контейнере меняется элемент, контейнер кидает сигнал об изменении (itemChanged). Далее необходимо предоставить доступ к контейнеру и его объектам как полный, так и только на чтение (т.е. использовать const). Как вы будете проектировать сигналы?

Сигнал вызывает (!) слоты, приконченные к нему (при директ коннекшне). Как вы собрались из кост ф-ии вызывать неконст слоты?

??
Типичный код приложения. Указатели используются для обобщения на полиморфизм.

Имея const Coontainer* вам доступен только const QList<const Item*>& items() const; Неужели по аналогии вы не хотите доступ только к void itemChanged(const Item* item) const?

C MOCом вы имея const Coontainer* можете подписаться на void itemChanged(Item* item) и изменить объект. С новыми сигналами/слотами (опирающимися на С++11) принципиально возможно такое ограничение, что вам будет доступен только void itemChanged(const Item* item) const, т.е. константность не теряется: по конст. указателю только конст. сигналы (как и методы).

To Авварон:
Сигнал ничего не делает, он только извещает о своём прибытии. А дальше уже система сигнал слотов на основании характеристик сигнала либо помещает его в очередь, либо вызывает слот.

to Akon:
Можно подписаться на константный сигнал и изменить данные, получив указатель на объект. Или неужто даже это проверяется моком? :D

Интересны др аспекты пятерки. Вот напр QWindow и связанные с ним классы. Там довольно много нового, и событийный цикл сильно изменен - сначала событие обрабатывается QWindow и только потом QWidget. Зачем так сделано? Зачем много нового кода "за сценой" (т.е. прямых выгод не дает)?

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

Кстати вот код константного сигнала. Нафиг такое надо?)

В общем исходя из обсуждаемого вопроса получаем ответ - Да, мок теперь проверяет соответствие написания const сигналов и объектов, но это ничего не значит :D

С чего бы? Хорошо, если не хотите, на чем основывается ваш вывод? Или в рамках класса Container предложите вашу реализацию.

Ммм, что он проверяет?

Где-то в доке кутешников написано, что лучше передавать по значению. Это разумно, так как, передавая указатель, вы форсите себя использовать Qt::DirectConnection (а вдруг успеет прийти эвент, к-ый удалит ваш айтем?). А в случае direct connection ваш сигнал может поменять состояние объекта (так как вызывает коллбеки) => объявлять его константным  - только путать людей.

Если вам так хочется перегружать сигнал для const Item*, так и перегружайте, зачем вам помечать сигнал как const? Тем более, что connect не проверяет на соответствие константность сигнала и слота (да и зачем?):
Единственное (!), зачем нужны const сигналы - это вызывать их из const методов (юзкейз редкий, но вдруг надо), дабы не делать самому const_cast. Но никто этого до сих пор не сказал.

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

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

Но в исходной задаче изменение айтема не подразумевается, там указатели для полиморфизма.

Рассматривать передачу по значению (читай - по const ссылке) как ошибку? Што?

Как обычно Igors выдвигает идеи будущего :D

Это сосем не одно и то же, не надо мухлевать  :)

Ну понятно же по контексту, что имелась ввиду передача по конст ссылке:)

Кстати, вот тут (http://m.blog.csdn.net/blog/CPP_CHEN/17528669) всякие адепты с++ говорят, что передавать по конст ссылке - плохо.

В тему - вот у меня проект, часть которого была сделана на 4.7, когда он появился. Сейчас проект существенно развивается, причем старая часть - не так существенно. Поскольку она используется в виде динамической библиотеки, её можно было бы оставить. Но я решил всё продолжать делать на 4.7. Почему? Я лучше сначала сделаю первую версию на 4.7. Это предсказуемо. А потом, если заказчик захочет побольше возможностей, которые потенциально может дать 5.х, я с заказчика возьму деньги за их реализацию, и заложу в них стоимость перевода на новую версию Qt.  ;) Объем проекта сейчас около 65000 строк, в финале ожидается около 100000.

Т.е. плагины на четверке, ядро на пятерке? Так не выйдет

Ах эти мечты, грезы :)

Если рассматривать любое новое Qt с точки зрения "что оно (конкретно) даст моему проекту", то ответ всегда будет один: почти ничего (или совсем ничего). Заказчика интересует предметная часть, новые фичи и.т.п., а не внутренняя модернизация