Russian Qt Forum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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