Overriding a protected pure virtual function with a signal
-
Is there any problem with overriding a protected pure virtual function with a signal in Qt?
The following seems to work...CppAbstractClass { protected: virtual void NotifyChangeToSubClass(int)=0; private: void DoTheThings() { NotifyChangeToSubClass(42); } }; class MyQtClass : public QObject, public CppAbstractClass { public: MyQtClass::MyQtClasss() { connect(this, SIGNAL(NotifyChangeToSubClass(int)), this, SLOT(MySlot(int))); } private slots: void MySlot(int Val) { qDebug() << Val; }; signals: void NotifyChangeToSubClass(int) override; };I wondered just because I always thought of Qt signals as public. Moc is fleshing out the implementation of NotifyChangeToSubClass like any other signal.
-
Is there any problem with overriding a protected pure virtual function with a signal in Qt?
The following seems to work...CppAbstractClass { protected: virtual void NotifyChangeToSubClass(int)=0; private: void DoTheThings() { NotifyChangeToSubClass(42); } }; class MyQtClass : public QObject, public CppAbstractClass { public: MyQtClass::MyQtClasss() { connect(this, SIGNAL(NotifyChangeToSubClass(int)), this, SLOT(MySlot(int))); } private slots: void MySlot(int Val) { qDebug() << Val; }; signals: void NotifyChangeToSubClass(int) override; };I wondered just because I always thought of Qt signals as public. Moc is fleshing out the implementation of NotifyChangeToSubClass like any other signal.
@mooglus Why don't you simply define NotifyChangeToSubClass as signal in CppAbstractClass? Why do you want to override it? There is no point in overriding signals, as code for signals is generated - you can't modify it's behaviour.
-
@mooglus Why don't you simply define NotifyChangeToSubClass as signal in CppAbstractClass? Why do you want to override it? There is no point in overriding signals, as code for signals is generated - you can't modify it's behaviour.
-
@mooglus said in Overriding a protected pure virtual function with a signal:
base class for code that isn't Qt
Why do you need a signal signature in there then?
-
@mooglus said in Overriding a protected pure virtual function with a signal:
base class for code that isn't Qt
Why do you need a signal signature in there then?
@Christian-Ehrlicher My base class calls a virtual function which is meant to be overridden by platform specific code. That code could be Qt, or objective c++, or whatever. In the case of Qt, rather than overriding the virtual function to then just emit another signal, I wanted to make that override the actual signal.
-
@Christian-Ehrlicher My base class calls a virtual function which is meant to be overridden by platform specific code. That code could be Qt, or objective c++, or whatever. In the case of Qt, rather than overriding the virtual function to then just emit another signal, I wanted to make that override the actual signal.
@mooglus said in Overriding a protected pure virtual function with a signal:
rather than overriding the virtual function to then just emit another signal, I wanted to make that override the actual signal.
You know what you're going to be suggested/told! Safer to leave it as a normal method, like the other code expects, and do whatever you want Qt-wise, like
emitting a signal, inside that method :) You may be fine with what you're doing, but for the sake of one extra function call it doesn't seem worth it.On a separate matter/bug-bear. You look like you're a reasonable programmer/Qt-er. So why are you still using the unhelpful, old-style
SIGNAL/SLOT()macros when you could & should be using the new style ones, which at least have compile-time support? :) -
@mooglus said in Overriding a protected pure virtual function with a signal:
rather than overriding the virtual function to then just emit another signal, I wanted to make that override the actual signal.
You know what you're going to be suggested/told! Safer to leave it as a normal method, like the other code expects, and do whatever you want Qt-wise, like
emitting a signal, inside that method :) You may be fine with what you're doing, but for the sake of one extra function call it doesn't seem worth it.On a separate matter/bug-bear. You look like you're a reasonable programmer/Qt-er. So why are you still using the unhelpful, old-style
SIGNAL/SLOT()macros when you could & should be using the new style ones, which at least have compile-time support? :)@JonB It's undoubtedly safer, but in larger classes these extra functions can add up to lots of boiler plate.
Well spotted, on the old-school SIGNAL/SLOT() :D We have lots of legacy code that hasn't been had these calls weeded out. I did notice as I was pasting the example, but thought it didn't matter too much for this example. -
@JonB It's undoubtedly safer, but in larger classes these extra functions can add up to lots of boiler plate.
Well spotted, on the old-school SIGNAL/SLOT() :D We have lots of legacy code that hasn't been had these calls weeded out. I did notice as I was pasting the example, but thought it didn't matter too much for this example.@mooglus said in Overriding a protected pure virtual function with a signal:
but in larger classes these extra functions can add up to lots of boiler plate.
Nah, I'm talking about a one-liner. You can even add it in-line in the
.hfile. If you're not prepared to add one line of code to an interface between two different products/systems you're in trouble. Even I would do it, and believe me I like minimal code! Totally my opinion/your choice of course. I'll leave others to answer your specific approach. -
Multiple inheritance with QObject could be problematic. When combining functionality with QObject classes I usually use composition rather than inheritance. I have run into issues with being able to copy objects based upon QObject. It also eliminates the use of templates for those classes. If I need a signal on an object that is not QObject based, and I can't or don't want to inherit from QObject. I will often create a subclass that gets created in the constructor and have it call methods on the parent object. I call this object a signal mule.
-
Multiple inheritance with QObject could be problematic. When combining functionality with QObject classes I usually use composition rather than inheritance. I have run into issues with being able to copy objects based upon QObject. It also eliminates the use of templates for those classes. If I need a signal on an object that is not QObject based, and I can't or don't want to inherit from QObject. I will often create a subclass that gets created in the constructor and have it call methods on the parent object. I call this object a signal mule.
-
@mooglus said in Overriding a protected pure virtual function with a signal:
Wouldn't you need to define an interface for your mule?
How would that be bad? If I need functionality I code that functionality.
@fcarney It just seems like more typing to provide functionality that inheritance provides. However, if you're in a situation where inheritance is causing you problems then it makes sense. I've read many times that it's good to favour composition over inheritance, in practice I often find it inconvenient. I would upvote you, but your reputation is 666, I could never ruin that ;)
-
@fcarney It just seems like more typing to provide functionality that inheritance provides. However, if you're in a situation where inheritance is causing you problems then it makes sense. I've read many times that it's good to favour composition over inheritance, in practice I often find it inconvenient. I would upvote you, but your reputation is 666, I could never ruin that ;)
-
@fcarney Interesting reply. I've not run into trouble (yet) with multiple inheritance and Qt. Wouldn't you need to define an interface for your mule? That sounds like a bit of a hassle.
@mooglus said in Overriding a protected pure virtual function with a signal:
I've not run into trouble (yet) with multiple inheritance and Qt.
If you do mean from
QObject(perhaps you don't) then that is surprising. Inheriting from more than oneQObject-derived class is problematic. There are various versions of Qt here, maybe things have changed over the years.https://stackoverflow.com/questions/8578657/qobject-multiple-inheritance/8578921
https://www.ics.com/blog/multiple-inheritance-qt
https://forum.qt.io/topic/88295/with-qt-5-6-is-it-possible-to-avoid-the-diamond-problem-when-signals-and-slots-are-defined-in-two-brancheshttps://doc.qt.io/qt-5/moc.html#multiple-inheritance-requires-qobject-to-be-first
If you are using multiple inheritance, moc assumes that the first inherited class is a subclass of QObject. Also, be sure that only the first inherited class is a QObject.
-
I wanted to inherit a templated class with a QObject. I ran into issues. Also multiple QObject inheritance doesn't work either.
@fcarney said in Overriding a protected pure virtual function with a signal:
I wanted to inherit a templated class with a QObject.
Works fine as long as you don't need moc stuff in the template
I ran into issues. Also multiple QObject inheritance doesn't work either.
Can not work to the parent-child relatonsship
Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
Visit the Qt Academy at https://academy.qt.io/catalog -
@fcarney said in Overriding a protected pure virtual function with a signal:
I wanted to inherit a templated class with a QObject.
Works fine as long as you don't need moc stuff in the template
I ran into issues. Also multiple QObject inheritance doesn't work either.
Can not work to the parent-child relatonsship
@Christian-Ehrlicher said in Overriding a protected pure virtual function with a signal:
Can not work to the parent-child relatonsship
Nor
moc, more specifically it confuses the hell out of the meta-object system (e.gQMetaObject). -
@fcarney It just seems like more typing to provide functionality that inheritance provides. However, if you're in a situation where inheritance is causing you problems then it makes sense. I've read many times that it's good to favour composition over inheritance, in practice I often find it inconvenient. I would upvote you, but your reputation is 666, I could never ruin that ;)
