QT4: "массив" подключений к сигналу? (отослать сигнал одному из мн-ва подключенных к сигналу объектов.?)

[Denjs]

Знатокам механизма сигналов и слотов.
Как отослать сигнал одному из мн-ва подключенных к сигналу объектов ?

Дано:
Есть объект "узел" - node. К нему подключается произвольное число "объектов" - obj
"объекты" obj - вообще разных классов, (но все классы - потомки одного общего абстрактного класса),
Их (obj) относительно "много", и подключаются они к одному-и-тому-же сигналу "узла" node. Заранее количество полключаемых obj не известно.
(подключением занимается некий диспетчер - это я к тому что "node" сам по себе не знает "что к нему подключено" и не занимается соединением себя и объектов obj. )

При генерации сигнала на node его естественно получают все obj. Это понятно )

Теперь собственно ситуация:
Мне надо адресовать сигнал только одному из подключенных объектов (от раза к разу - разным объектам).
Пока не нашел ничего лучшего как добавить в сигнал некий идентификатор(строковой например) нужного объекта obj (будем считать что мы их как-то узнали, как - сейчас не важно)
а в самом obj проверять ему-ли этот сигнал адресован.

Но мне это не нравится по причине того что все объекты будут реагировать на сигнал и проверяться... не знаю на сколько сильно это может "тормознуть" но мне это не нравится.

Хочется видеть какой-нибудь механизм массива подключений к сигналу - по мере появления новых подключений он растет - фактически давая
мне доступ к отдельным связям-подключениям и способность генерировать сигналы в отдельное - четко заданное подключение - что бы остальные объекты даже об этом не знали.

Вот примерно так... ещё конечно буду рыться...
____________________________________________________________
Делать массив ссылок на public-функции obj не предлагать... )
не айс это... и не "в духе" QT.

"Жонглировать" полключениями тоже "не ice" - отсылка сигнала заданному объекту - это потребность "узла",
а "диспетчер", имеющий "привелении и знания как об узле так и о всех объектах" для соединения объетов
об этом знать не должен.

[sarutobi]

Не совсем понятен путь прохождения сигнала. node отправляет сигнал obj сам или отправляет сигнал диспетчеру, а уже диспетчер рассылает сигнал?
>Мне надо адресовать сигнал только одному из подключенных объектов (от раза к разу - разным объектам).
Один и тот же сигнал? но разным объектам? Кому отправить - определяет node? Возможно ли ввести иерархию типов сигналов?

[eduard_pustobaev]

Честно говоря звучит слишком сложно. Хотя вопрос конечно всплывает не первый раз.
По мне, так проще не коннектить кучу слотов, а по мере надобности подключать/отключать необходимые.
Мну всегда пишет слоты типа setConnections(), где создаёт/рвёт связи сигнал-слот.
Вообще хотелось бы конкретный пример. А то теоретизировать-то можно, но не факт, что имеет смысл.

[Liksys]

Насколько я понял, можно банально сделать класс от QObject, который и будет разруливать все эти подключения. То есть он реагирует на все сигналы, а посылает только один нужному объекту. В качестве идентификаторов можно использовать имя объекта, оно должно быть уникально в пределах проги. Или какой-нить числовой идентификатор. Потом составлять правила, типа прохождения такого-то сигнала с такими-то данными и идентификатором адресуется тому-то.

[Folderx]

Но мне это не нравится по причине того что все объекты будут реагировать на сигнал и проверяться... не знаю на сколько сильно это может "тормознуть" но мне это не нравится.

Все объекты не срабатывают по сигналу если не приходит второй сигнал с идентификатором.

[Denjs]

В общем решил я переработать структуру объектов... от "проблемы" не избавился, но думаю ресурсов такое решение в работе юудет съедать меньше.

Суть проблемы в первоначальном её варианте была в следующем (кто хотел пример? "вотъ:" ) - есть объект "узел печати" (тот самый "node" описанный выше) - включающий очередь заданий на печать и некий предварительный интерпретатор.
есть множество "объектов принтеров"(те самые "obj") с которыми общается узел печати.
по мере разбора очередного задания "узел" активно посылает переработанные данные на "объект принтера", которые там преобразуются в низкоуровневые команды конкретного оборудования.

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

Обошел опасения переработав структуру объектов - определил что для каждого "принтера" будет создаваться индивидуальная копия "узла печати" а рассылка заданий на печать будет осушествляться от третьего объекта (неким "менеджером направлений печати", хотя это громко сказано т.к. его задача просто "собирать на себе" подключения "узлов печати" и "ретранслировать" им поступающие задания.(хотя тут наверное разумно отказаться от идеологии синалов/слотов и реализовать "стародревний массив ссылок"... но я ещё буду думать...) )
в общем - таким образом множественный запрос будет возникать гораздо реже - только при передаче задания в очередь - и "активное" общение "анализатора задания"(на выходе очереди) и "объекта принтера" не будет приводить к постоянной активации множества объектов.

Кроме того - такой вариант позволяет реализовать параллельную печать на нескольких "объектах принтеров" что удобно.
(выстраивать цепочки, создавать и соединять объекты друг с другом по прежнему будет некий "диспетчер" (стоящий "над" этой всей песочницей). но это уже не суть. )
______________
В общем был найден "почти путь обхода" проблемы и топик можно закрыть.

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