Qt 4.7 или 5.

[Akon]

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

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

[Авварон]

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

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

[Akon]

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

Код:

class Container
{
public:
	const QList<Item*>& items();
	const QList<const Item*>& items() const;
	
Q_SIGNALS:
	void itemChanged(Item* item);
	void itemChanged(const Item* item) const;
	
private:
	QList<Item*> items_;
};

Имея 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, т.е. константность не теряется: по конст. указателю только конст. сигналы (как и методы).

[Bepec]

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

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

[Igors]

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

[Авварон]

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

Код:

class Container
{
public:
	const QList<Item*>& items();
	const QList<const Item*>& items() const;
	
Q_SIGNALS:
	void itemChanged(Item* item);
	void itemChanged(const Item* item) const;
	
private:
	QList<Item*> items_;
};

Имея 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, т.е. константность не теряется: по конст. указателю только конст. сигналы (как и методы).

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

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

Код:

// SIGNAL 1
void Application::changed() const
{
    QMetaObject::activate(const_cast< Application *>(this), &staticMetaObject, 1, 0);
}

[Bepec]

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

[Akon]

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

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

[Авварон]

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

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

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

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

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

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

Код:

class Application 
{
...
public slots:
    void newWindow();
signals:
    void changed() const;
...
};

    connect(this, &Application::changed, this, &Application::newWindow);

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

[Igors]

... что лучше передавать по значению. Это разумно, так как,

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

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

[Авварон]

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

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

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

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

[Bepec]

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

[Igors]

передачу по значению (читай - по const ссылке)

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

[Авварон]

передачу по значению (читай - по const ссылке)

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

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

Кстати, вот тут всякие адепты с++ говорят, что передавать по конст ссылке - плохо.

[Гурман]

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