Вложенные типы и опережающие описания

[Akon]

Дабы не плодить лишних зависимостей времени компиляции часто применяется опережающее описание (повсеместно используется в Qt).
Пример:

Код:

#include <QtGui/QMainWindow>

class QSystemTrayIcon;

class MainWindow : public QMainWindow
{
	...
private:
	QSystemTrayIcon* trayIcon_;
};

Здесь используется опережающее описание QSystemTrayIcon. Все бы ничего, но пусть требуется обработка сигнала QSystemTrayIcon::activated (QSystemTrayIcon::ActivationReason):

Код:

#include <QtGui/QMainWindow>
#include <QtGui/QSystemTrayIcon>  // подключается из-за QSystemTrayIcon::ActivationReason

class MainWindow : public QMainWindow
{
	...
private:
	QSystemTrayIcon* trayIcon_;
	// коннетится к сигналу QSystemTrayIcon::activated (QSystemTrayIcon::ActivationReason)
	Q_SLOT void iconActivated(QSystemTrayIcon::ActivationReason reason);
};

Поскольку появляется зависимость от вложенного перечисления QSystemTrayIcon::ActivationReason, опережающее описание больше не катит, и приходится подключать заголовок (опережающее описание вложенного типа в общем случае не сделаешь). Оно то может и не проблема, просто как-то выбивается из общей концепции. Если бы вы проектировали QSystemTrayIcon, как поступили бы?

[_OLEGator_]

Я называю это предобъявлением.
Вопрос по проектированию - цель создания зависимости от QSystemTrayIcon::ActivationReason и какая обработка в слоте?

[LisandreL]

Вопрос по проектированию - цель создания зависимости от QSystemTrayIcon::ActivationReason и какая обработка в слоте?

Прицепить слот к сигналу QSystemTrayIcon::activated( QSystemTrayIcon::ActivationReason reason ) - очевидно же.
ActivationReason'ы очень разные, без параметра тут не обойтись.

[Akon]

В идеале хотелось бы опережающее описание:

Код:

class QTrayNotifyIcon {
    enum ActivationReason;
}

В общем случае такого нет, отсюда и проблема.

[ssoft]

В идеале хотелось бы опережающее описание:

Код:

class QTrayNotifyIcon {
    enum ActivationReason;
}

В общем случае такого нет, отсюда и проблема.

Никаких проблем в этом нет.
Здесь рассмотрены две разные архитектурные зависимости.

Предварительное объявление необходимо при ИСПОЛЬЗОВАНИИ НЕЗАВИСИМЫХ типов данных (1-й вариант).

Если же есть явная ЗАВИСИМОСТЬ одного типа от другого, в данном случае используются внутренние данные QSystemTrayIcon при объявлении метода, тогда однозначно только #include.

[_OLEGator_]

to LisandreL:
я имел в виду проектирование и возможность вынести обработку в другое место.

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

[andrew.k]

С такой ситуации в случае енумов, я использую int в методе вместо enum.
Не всегда правда.

[LisandreL]

С такой ситуации в случае енумов, я использую int в методе вместо enum.
Не всегда правда.

Сигнал со слотом не сконнектятся при разных (пусть и приводимых) типах.

[andrew.k]

С такой ситуации в случае енумов, я использую int в методе вместо enum.
Не всегда правда.

Сигнал со слотом не сконнектятся при разных (пусть и приводимых) типах.

Ну так, а зачем их делать разными?

[LisandreL]

Ну так, а зачем их делать разными?

Потому, что вы это 2 постами выше предложили. 
Сигнал QSystemTrayIcon::activated( QSystemTrayIcon::ActivationReason reason ) нам достаётся вместе с Qt поэтому тип тут нам не изменить.
Вы говорите, что «С такой ситуации в случае енумов, я использую int в методе вместо enum.», но именно в такой, как указанно, ситуации int использовать нельзя, так как connect не сработает.

[Igors]

...Оно то может и не проблема, просто как-то выбивается из общей концепции.

Это также бывает когда хотелось бы inline в h файле. Не думаю что концепция здесь как-то нарушается. Вы используете конкретные подробности QSystemTrayIcon, стало быть пора от предварительного описания перейти к полному - это нормально.

А все-таки как хорошо проектировать "идеальный код" (эх, живут же люди )

[andrew.k]

Ну так, а зачем их делать разными?

Потому, что вы это 2 постами выше предложили. 
Сигнал QSystemTrayIcon::activated( QSystemTrayIcon::ActivationReason reason ) нам достаётся вместе с Qt поэтому тип тут нам не изменить.
Вы говорите, что «С такой ситуации в случае енумов, я использую int в методе вместо enum.», но именно в такой, как указанно, ситуации int использовать нельзя, так как connect не сработает.

Я говорил не применительно к этому сигналу, а как способ избежать лишнего инклуда.
Иногда можно поступить так.
Вопрос в топике был "Если бы вы проектировали QSystemTrayIcon, как поступили бы?", а не вечный "что делать?"