Сигналы и слоты в плагинах

[lighting]

Есть задача, программа должна управлять различными железками. Для унификации протокол общения с каждой конкретной железкой выносится в отдельный плагин и подгружается по мере надобности. Насколько я понял интерфейс не может наследоваться от QObject следовательно сигналы и слоты ему недоступны. Со слотами проблема решаемая - их можно вызывать как методы, а вот как быть с сигналами, как получать инфу от плагина?

[Странник]

Есть задача, программа должна управлять различными железками. Для унификации протокол общения с каждой конкретной железкой выносится в отдельный плагин и подгружается по мере надобности. Насколько я понял интерфейс не может наследоваться от QObject следовательно сигналы и слоты ему недоступны. Со слотами проблема решаемая - их можно вызывать как методы, а вот как быть с сигналами, как получать инфу от плагина?

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

[Sancho_s_rancho]

Интерфейс без наследования от QObject, но с

Код:

virtual QObject* pluginObject() = 0;

А в плагине

Код:

class MyClass : public QObject, public ModuleInterface
{
    Q_OBJECT
    Q_INTERFACES(ModuleInterface)
public:
virtual QObject* pluginObject() { return this; }

[xokc]

Если не нравится использование этого метода (мне не нравится):

Код

C++ (Qt)
virtual QObject* pluginObject() { return this; }
 

можно в основной программе делать примерно так:

Код

C++ (Qt)
QPluginLoader loader("plugin");
connect(loader.instance(), SIGNAL(pluginSignal()), SLOT(appSlot()));
 

[andrew.k]

можно в основной программе делать примерно так:

Код

C++ (Qt)
QPluginLoader loader("plugin");
connect(loader.instance(), SIGNAL(pluginSignal()), SLOT(appSlot()));
 

Чтобы экземпляр плагина мог испускать сигналы (по условию задачи), он все-таки должен быть наследован от QObject.
А т.к. сигналы как и все прочее скорее всего будут унифицированы, наследование должно присутствовать на уровне интерфейса.
Можно конечно перенести объявление сигналов в реализацию интерфейса, но не думаю, что это будет красиво, скорее наоборот.

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

[lighting]

Пробую объявить интерфейс так:

Код

C++ (Qt)
#ifndef INTERFACES_H
#define INTERFACES_H
#include <QObject>
 
class QString;
class CameraInterface : public QObject
{
    Q_OBJECT
public:
    virtual ~CameraInterface() {}
    virtual void powerOn();
    ...
    virtual void extendedCommand(QString command);
 
signals:
    void powerStateCahnged(bool state);
    void backlightStateChanged(bool state);
};
 
Q_DECLARE_INTERFACE(CameraInterface, "ru.myCompany.myApp.cameraInterface/1.0")
 
#endif // INTERFACES_H
 

При попытке сборки валятся ошибки вида:
debug/moc_interfaces.o:moc_interfaces.cpp:(.rdata$_ZTV15CameraInterface[vtable for CameraInterface]+0x38): undefined reference to `CameraInterface::powerOn()'
количеством равным кол-ву виртуальных методов. Насколько я понимаю компилятор пытается найти реализацию вирутальных функций, но зачем он это делает мне не понятно.

Читал вот эту тему http://www.prog.org.ru/topic_8357_0.html никак не могу взять в толк для чего Dendy и Константин советуют в интерфейсе только передавать указатель на создаваемый класс, а не указывать список доступных методов. Я себе представлял что в интерфейсе надо собирать общие для поддерживающих протокол железок методы, чтобы вызывающему плагин приложению было наплевать на реализацию класса для конкретной железки, а советуют делать наоборот 

[andrew.k]

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

Он же не знает, что ты недоучил с++

методы должны быть абстрактными, не?

[lighting]

да, не все то абстрактно, что виртуально

[andrew.k]

да, не все то абстрактно, что виртуально

Заодно QString передавай по константной ссылке.

[xokc]

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

А я нигде и не утверждал, что MyClass не не должен наследоваться от QObject, как раз наоборот. Я имел ввиду, что метод pluginObject() - лишний, потому, что loader.instance() возвращает ровно то же, что pluginObject().

Пробую объявить интерфейс так:
class CameraInterface : public QObject

CameraInterface НЕ ДОЛЖЕН наследоваться от QObject! От QObject надо наследоваться классом, который реализует абстрактные методы из CameraInterface (см. пример от Sancho_s_rancho с классом MyClass).

[andrew.k]

CameraInterface НЕ ДОЛЖЕН наследоваться от QObject! От QObject надо наследоваться классом, который реализует абстрактные методы из CameraInterface (см. пример от Sancho_s_rancho с классом MyClass).

Если ты так решил, это не значит, что все должны так делать.
Каким раком тогда moc сгенерит код для сигналов и слотов интерфейса?
Еще как ДОЛЖЕН.

[lighting]

CameraInterface НЕ ДОЛЖЕН наследоваться от QObject! От QObject надо наследоваться классом, который реализует абстрактные методы из CameraInterface (см. пример от Sancho_s_rancho с классом MyClass).

andrew.k меня опередил, но я добавлю - если CameraInterface не будет наследоваться от QObject то как тогда мое приложение использующее плагины узнает о том какие что плагин будет посылать сигналы. Собственно заморочку с плагинами я затеял именно для того чтобы написать нужное кол-во плагинов реализующих конкретный функционал (SonyCamera, AxisCamera, TandbergCamera и т.п.) без необходимости правок в основной программе. Она не должна знать о том что есть все это многообразие, а работать должна со всеми ими через CameraInterface.

[andrew.k]

Можно конечно не наследовать от QObject, а добавить метод возвращающий экземпляр абстрактного рабочего класса (а реализация будет его в наследниках).
Что-нибудь типа

Код

C++ (Qt)
virtual BaseCameraWorker * createWorkerObject() = 0;

Если это действительно необходимо, по соображениям гибкости, то почему нет. Это уже должен автор решать, надо оно ему или нет.
Но не вижу в этом подходе преимуществ (для рассматриваемого примера), ровно как и недостатков в рассматриваемом выше подходе. Меня не пугает интерфейс наследованный от QObject.

Можно абстрагироваться сколько угодно в глубь и в ширь, но как говорится чем круче джип, тем дальше ехать трактору)

[xokc]

Каким раком тогда moc сгенерит код для сигналов и слотов интерфейса?
Еще как ДОЛЖЕН.

Давайте-ка ещё раз и по-спокойнее. Наследоваться от QObject (а так же от CameraInterface) будут классы SonyCamera, AxisCamera, TandbergCamera и т.д. Для них же, а не для CameraInterface, moc сгенерит код для всех их сигналов и слотов. Основному приложению достаточно знать только методы, имеющиеся в CameraInterface и общие для ВСЕХ его наследников сигналы/слоты. В основном приложении на этапе компиляции совсем не нужны moc реализации всего того, что он нагенерит для плагинов.

Вот даже пример набросал.

[andrew.k]

Каким раком тогда moc сгенерит код для сигналов и слотов интерфейса?
Еще как ДОЛЖЕН.

Давайте-ка ещё раз и по-спокойнее. Наследоваться от QObject (а так же от CameraInterface) будут классы SonyCamera, AxisCamera, TandbergCamera и т.д. Для них же, а не для CameraInterface, moc сгенерит код для всех их сигналов и слотов. Основному приложению достаточно знать только методы, имеющиеся в CameraInterface и общие для ВСЕХ его наследников сигналы/слоты. В основном приложении на этапе компиляции совсем не нужны moc реализации всего того, что он нагенерит для плагинов.

Код

C++ (Qt)
class CameraInterface
{
//Q_SIGNALS:
//   void initDone();
// Если тут не будут описаны сигналы
};
 
class SonyCamera : public QObject, public CameraInterface
{
  void doInit()
  {
    ...
   emit initDone();
    // то тут ты не сможешь испускать этот сигнал.
  }
 
// и тогда тебе надо будет описывать его тут:
Q_SIGNALS:
   void initDone();
};
 
class AxisCamera : public QObject, public CameraInterface
{
...
// и еще тут:
Q_SIGNALS:
   void initDone();
};
 
class TandbergCamera : public QObject, public CameraInterface
{
...
// и еще тут:
Q_SIGNALS:
   void initDone();
};
 
//И во всех остальных классах придется делать копипасту.