Interfaces must inherit QObject?!

[JKSH]

@KroMignon said in Interfaces must inherit QObject?!:

I don't remember where I found this in Qt documentation (and not remember why), but QObject (or a QObject based class) must be the first class in inheritance list.

...

@JonB said in Interfaces must inherit QObject?!:

I should like a reference for this.

https://doc.qt.io/qt-5/moc.html#multiple-inheritance-requires-qobject-to-be-first

[JonB]

@JKSH said in Interfaces must inherit QObject?!:

https://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.

Thank you for this reference. However, unless I read it wrong, this does not address the @idlefrog's case or @KroMignon's solution.

In the example in the docs

class SomeClass : public QObject, public OtherClass

Here there is no indication that the second class, OtherClass, itself inherits QObject. And it states explicitly

Also, be sure that only the first inherited class is a QObject.

@idlefrog is asking specifically about multiple inheritance where both classes come from QObject, and that is what i was trying to answer.

I see that several members, including @kshegunov, have up-voted your post. I would welcome clarification on this issue, please, as my understand is that multiple inheritance where both involve QObject is not supported, regardless of ordering?

[KroMignon]

@JonB said in Interfaces must inherit QObject?!:

I see that several members, including @kshegunov, have up-voted your post. I would welcome clarification on this issue, please, as my understand is that multiple inheritance where both involve QObject is not supported, regardless of ordering?

I up-voted @JKSH post, because it gives the link to documentation I talking about.
But, the reply to your question: according to documentation QObject multiple inheritance (diamond inheritance) is not allowed/possible.

[JonB]

@KroMignon Thanks @Kro, understood, I'm just seeking clarification because this is all getting a bit muddy.... :)

[idlefrog]

It seems to me that for a class where you inherited perhaps a set of interfaces and one QObject, you can't inherit any other QObject class. e.g.

class RealCake: public QObject, public ICake, public IEdible{}

class PlasticCake: public QObject, public ICake {}

class JokeCake: public PlasticCake, public RealCake{}

The JokeCake is not allowed in the world of Qt. Pity!

[kshegunov]

@JonB said in Interfaces must inherit QObject?!:

I see that several members, including @kshegunov, have up-voted your post. I would welcome clarification on this issue, please, as my understand is that multiple inheritance where both involve QObject is not supported, regardless of ordering?

If both classes inherit from QObject you enter virtual-inheritance-land, where the night is dark and full of terrors ... and it's simply not supported by moc (last sentence of the mentioned link). Otherwise multiple inheritance is fine, good, expected and so on (provided you use it properly), and is supported both by the language and by Qt with the minor note about base class order.

[kshegunov]

@idlefrog said in Interfaces must inherit QObject?!:

The JokeCake is not allowed in the world of Qt. Pity!

Even if it were allowed, you're using it incorrectly. C++ is hard, man, it's just the way it is.

[JonB]

@idlefrog
Yes indeed that is precisely my understanding (unless mistaken). You must not inherit multiple times from QObejct, whether directly or indirectly, and regardless of order. Because of moc requirement/limitation.

I still refer you back to QObject Multiple Inheritance. Ah, hang on, I think the solution I had in mind is at https://stackoverflow.com/a/18113601/489865 "the Qt way of doing this is like this...." But now I see that includes

I am amazed that this actually works, but bummed out by the fact that it requires the old-style SIGNAL()/SLOT() syntax...

[Not my language!] Which is a bu**er :(

[kshegunov]

@JonB said in Interfaces must inherit QObject?!:

I still refer you back to QObject Multiple Inheritance. Ah, hang on, I think the solution I had in mind is at https://stackoverflow.com/a/18113601/489865 "the Qt way of doing this is like this...." But now I see that includes

This is simply an abomination. Signals act polymorphically without the need to declare them as pure virtual in interfaces. Slots are a different kettle of fish, they work just fine with overriding.

(Edit)
Addendum:

Yes indeed that is precisely my understanding (unless mistaken). You must not inherit multiple times from QObejct, whether directly or indirectly, and regardless of order. Because of moc requirement/limitation.

Just to spill it as explicitly and bluntly as I possibly can:
You shall not derive a class from the same base multiple times (directly or indirectly) if you don't intimately know what's the difference between:

class Derived : public Base

and

class Derived : virtual public Base

[JonB]

@kshegunov
Yeah, I didn't notice the virtual on the signal. That's the trouble with assuming an accepted solution with 60 up-votes must be good!

It shows a lot of people are obviously struggling with this. How then can the OP here arrange to write an "interface" which inherits from QObject and apply it to classes which inherit from QObject too?

Ohhhh, maybe I misunderstood? Only now do I see that OP did not originally say that ICake needed QObject itself. Only that he put it first in the class inheritance list before QObject and that upset moc. I get it now, and why public QObject, public ICake works here. OK, but what about if OP did want multiple QObject inheritance, any way without the "abomination" ?

[kshegunov]

@JonB said in Interfaces must inherit QObject?!:

OK, but what about if OP did want multiple QObject inheritnace, any way without the "abomination" ?

He shan't do it. Also read the addendum I added to my previous post.

[JonB]

@kshegunov
Is that a requirement of C++? The OP claimed

class VictoriaSpongeCake : public ICake, public QObject

So if I change ICake to inherit like this:

class ICake: public QObject

It all compiles without a problem.

That is not quoting me, it is quoting him.

[kshegunov]

@JonB said in Interfaces must inherit QObject?!:

Is that a requirement of C++?

It is not a requirement, but there's a significant difference.
Here's links, I know you love them sources:
https://isocpp.org/wiki/faq/multiple-inheritance (What is the “dreaded diamond”? being key)
https://en.cppreference.com/w/cpp/language/derived_class (Virtual base classes is relevant)

[JonB]

@kshegunov
Yeah, thanks, this looks good. public virtual Base, that's a new one for me, I like it. The more complexity in C++ the better... ;-)

[JKSH]

@JonB said in Interfaces must inherit QObject?!:

@kshegunov
Is that a requirement of C++? The OP claimed

class VictoriaSpongeCake : public ICake, public QObject

So if I change ICake to inherit like this:

class ICake: public QObject

It all compiles without a problem.

That is not quoting me, it is quoting him.

OP forgot to re-run qmake (or delete the build directory) after making ICake inherit QObject and adding the Q_OBJECT macro.

@JonB said in Interfaces must inherit QObject?!:

How then can the OP here arrange to write an "interface" which inherits from QObject and apply it to classes which inherit from QObject too?

They can't.

QObjects are designed to be "identity objects", as opposed to "value objects": https://doc.qt.io/qt-5/object.html#qt-objects-identity-vs-value (for example, an image is a value but a window is an identity). I'd say that an "interface object" is neither an identity nor a value.

One more thought: If a class inherits from 2 differnent QObjects, what should obj->staticMetaObject.superClass() return?

P.S. I think you'll enjoy the thoroughness of this article: https://www.ics.com/blog/multiple-inheritance-qt

[JonB]

@JKSH said in Interfaces must inherit QObject?!:

OP forgot to re-run qmake (or delete the build directory) after making ICake inherit QObject and adding the Q_OBJECT macro.

They can't.

Thank you, this makes a lot more sense then!