Как обработать сигнал одним слотом из подключенных?

[GreatSnake]

Выстави QApplication::property().

qApp один на всю программу. Соответственно и флажок будет одним.

Внимательно прочитай вопрос, на который был мой ответ.

Ко всем этим объектам подключен один сигнал одного объекта-источника, одновременно.

Если позволяет архитектура, такой флажок можно завести в объекте-источнике ( sender() ).

[Гурман]

Уже сделал на invokeMethod(). Проще всего, ничего лишнего. Реестр плагинов имеется, нашел в нем первый подходящий и не занятый, и в нем вызвал метод. У всех подходящих плагинов имя этого метода одинаковое, поскольку наследуют от одного класса. Всё. Работает. Даже устанавливать соединения не требуется.

[Гурман]

Ко всем этим объектам подключен один сигнал одного объекта-источника, одновременно.
Если позволяет архитектура, такой флажок можно завести в объекте-источнике ( sender() ).

В архитектуре постулировано, что плагины с родительским приложением и наоборот общаются только через сигнал-слоты. А они при обычных соединениях значения не возвращают. Но вот invoikeMethod() позволяет получить возвращаемое значение, хотя является эквивалентом временного соединения сигнал-слот, поскольку работает на том же механизме.

[Igors]

Уже сделал на invokeMethod(). Проще всего, ничего лишнего. Реестр плагинов имеется, нашел в нем первый подходящий и не занятый, и в нем вызвал метод. У всех плагинов имя этого метода одинаковое, поскольку наследуют от одного класса. Всё. Работает. Даже устанавливать соединения не требуется.

Безыдейно (хотя и просто и работает)

[Гурман]

Безыдейно (хотя и просто и работает)

Принцип бритвы Оккама - самое простое решение является самым правильным. 

[GreatSnake]

Безыдейно (хотя и просто и работает)

Имхо в данном случае самое простое решение.
И если бы автор изначально по-конкретнее поставил задачу, такого количества костылей ему бы не было предложено 

[Гурман]

Хе... Заметил попутно такой факт, не совсем в тему, но в принципе можно было бы использовать и тут - если класс хранения переменной в плагине статический (static, или глобально без модификатора, или extern), и плагин загружается из той же DLL повторно, то эта переменная будет общей для всех загруженных версий плагина (динамическая память и стек у каждого будут, разумеется, свои). Но если плагин загрузить с таким же кодом, но из DLL с другим именем (из копии файла DLL), то статически хранимые переменные будут для всех версий свои. По крайней мере, так в вениках. Как в Линухе еще не знаю, до сборки проекта в нем еще далеко.

По идее, все правильно, поскольку статически хранимые переменные размещаются в общем сегменте данных, который вместе с сегментом кода отображается в оперативную память процессора. Но неоднократно читал (делать такое не приходилось), что в вениках такие переменные у каждого экземпляра плагина свои - правда это могло иметь отношение к динамическим библиотекам и плагинам, создаваемым с помощью мелкомягкого компоновщика. Тут же GNUтое всё... Наверняка и в Линухе всё также будет работать, но на 100% в мультплатформенном приложении полагаться на такое размещение нельзя, могут быть проблемы.

[Igors]

Замеченный Вами факт я использовал не один десяток лет - когда не было нормального способа API заставлял юзера цеплять один плагин в неск местах приложения, и дальше взаимодействие через общие переменные.

и плагин загружается из той же DLL повторно,

Нет никакой "повторной загрузки" - просто увеличивается счетчик использования dll.

(динамическая память и стек у каждого будут, разумеется, свои).

Не свои а вызывающего

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

Нет. Напр если 5 процессов загрузили одну dll все используют одну копию кода и 5 копий данных. В Вындоуз можно сделать данные общими, но надо сильно постараться.

На никсовых ОС все то же самое, читайте dlopen и dlsym. Помню правил такой баг: загрузил либу - выгрузил - загрузил опять. Оба-на! Переменные остались с предыдущей загрузки

[Гурман]

и плагин загружается из той же DLL повторно,

Нет никакой "повторной загрузки" - просто увеличивается счетчик использования dll.

Да, нашел уже описание. Странно, что раньше это не попадалось.

(динамическая память и стек у каждого будут, разумеется, свои).

Не свои а вызывающего

Я имел в виду - разные. Это понятно, что у приложения куча одна и стек один.

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

Нет. Напр если 5 процессов загрузили одну dll все используют одну копию кода и 5 копий данных. В Вындоуз можно сделать данные общими, но надо сильно постараться.

Это если 5 разных процессов. Я имел в виду случай загрузки одной DLL несколько раз одним и тем же процессом. Статические данные вместе с кодом отобразились один раз, и как вы выше сказали, затем только увеличивается счетчик использования - не только сегмента кода, но и сегмента данных.

На никсовых ОС все то же самое, читайте dlopen и dlsym. Помню правил такой баг: загрузил либу - выгрузил - загрузил опять. Оба-на! Переменные остались с предыдущей загрузки

Вот это теперь для меня вполне обоснованно.

Сижу теперь и думаю, что в реальной жизни будет лучше, если по условию для каждого плагина надо иметь собственные сегменты данных - плодить копии плагинов и грузить их как отдельные, либо переделывать плагины, чтобы у них не было статических данных, все только динамические. Первый вариант проще. Но это приведет к многократной загрузке и дублированию в памяти одинакового кода, хотя он и не страшно смертельного объема, около 800 КБ на плагин, но может вырасти до 2 МБ. Максимум в реальности будет загружаться 10-20 таких плагинов. В принципе, не смертельно. Но надо еще придумать, как и когда создавать копии. Второй вариант - это переделка всего такого плагина, а он... сложный. И давно написанный и хорошо отлаженный. И статические данные там неспроста появились.

[Igors]

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

Только динамические - необязательно, нередко что-то даже лучше иметь статичным. Но основные/рабочие параметры да, в куче и у каждого экземпляра свои. Для этого есть хороший критерий: multi-threading. Как только потребуется параллельное выполнение вся статика рухнет.

Боязнь переделок понятна - плагинов-то совсем не один, могут быть писаны давно и хз как теперь компилить. Но все же чем раньше - тем лучше. Возможный подход: на фазе инициализации плагин выделяет блок памяти где размещает рабочие данные/параметры. Адрес этого блока возвращается хосту, а тот при каждом вызове плагина опять подает ему этот же адрес.

[Гурман]

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