QtForum.org

Yo all -

Does anyone have good reasons for or against inheriting slot fns, rather than getting Qt to call derived them directly? E.g. which is better below, scenario A or scenario B?:


Scenario A: using C++ inheritance on a slot
==================================

class MyBaseA : public QObject
{
Q_OBJECT
. . .
public slots:
virtual void mySlot(); // overridable slot
};

class MyDerivedA : public MyBaseA
{
public:
void mySlot(); // this is NOT a slot, just an override of MyBaseA::mySlot()
};

MyBaseA::makeConnections()
{
// Connects to slot MyBaseA::mySlot(). However, MyDerivedA::mySlot()
// always gets called thanks to C++ inheritance.
connect( obj, SIGNAL(mySignal()), this, SLOT(mySlot()));
}


Scenario B: Qt calls the a slot directly
=============================

class MyBaseB : public QObject
{
Q_OBJECT
. . .
public slots:
void mySlot(); // ordinary slot
};

class MyDerivedB : public MyBaseB
{
Q_OBJECT // (incidentally, is this required ???!)

public slots:
void mySlot(); // ordinary slot
};

MyBaseB::makeConnections()
{
// Connects to either MyBaseB::mySlot() or MyDerivedB::mySlot(),
// depending on whether *this is MyBaseB or MyDerivedB.
connect( obj, SIGNAL(mySignal()), this, SLOT(mySlot()));
}


It seems to me that scenario A is superior: we only require a single slot in the base class - and so only a single Q_OBJECT framework (i.e. MOC file).

In scenario B, we have two independent moc frameworks (i.e. moc files), and it may not be obvious which of the two mySlot() fns is called by MyBaseB::makeConnections(): it all depends on whether *this is a pointer to a MyBaseB or to a MyDerivedB.

If anyone has anything to add, or can see something wrong in my argument, please reply! Cheers!

MyDerivedA::mySlot() was made an ordinary non-slot fn precisely to remove the Qt framework from class MyDerivedA. I have other classes similarly derived off MyBaseA, and it seemed that rather than adding Q_OBJECT to each of them I only need a single slot in the base class. Qt only connects to this base class (MyBaseA), sure, but thanks to the slot being virtual, the vtable will call MyDerivedA::mySlot() (or whichever derived class is involved).

In scenario B - again please consider not just MyDerivedB, but multiple subclasses - Q_OBJECT must be added to every derived class, which seems wasteful.

So rather than applying the Qt framework to every derived class (Screnario B), inheriting a slot fn means I only need apply it to the base class and C++ the vtable does the rest. Do you think this sounds reasonable? To quote from Qt Assistant (page 'Signals and Slots'):

"You can also define slots to be virtual, which we have found quite useful in practice."

Is this one such reason for using virtual slots?

Wysota, I don't understand: MyDerivedB::mySlot() has been added as new slot, so surely you do need Q_OBJECT? Without Q_OBJECT in MyDerivedB, qt_invoke() won't be expanded out so how wil MyDerivedB::mySLot() ever be called?

Am I missing something?

Petr,

Maybe the name mySlot() helps somewhat! (no offence!)
Sure, I agree things are not crystal clear with ScenarioA, but one could make it clearer with the following:

class MyDerivedA :public MyBaseA
{
...
public:
virtual mySlot(); // override of slot in MyBasA
};

Since slots are just normal C++ fns, I thought it better to use native C++ inheritance and get MyDerivedA::mySlot() called this way rather than adding a fresh Qt framework into the derived class.

Thanks to everyone's input: I'm still unconvinced which scenario is best, however. Humph ...