Multiple inheritance from QObject (QObject is an ambiguous base of ...)

bdajeje · wrote on 2 Dec 2011, 19:25

Hello everyone.
I already saw some topics about this problem, but don't found or don't understood any solution.

Currently I have two class, let's call them 'X' and 'Y'.
Y inherited QObject.
X inherited QLabel and Y.

As you can see there's ambiguity between QObject from QLabel and QObject from Y.

For example I have an issue when I write:
connect( X, SIGNAL( aSignal() ), this, SLOT( aSlot() ) );

Because of "QObject is an ambiguous base of X".

Is anyone have a solution for this ?

PS: I tried to dynamic_cast my X class to a QObject* but didn't change anything.

bdajeje · wrote on 2 Dec 2011, 20:00

So, I manage to resolve my problem by dynamically casting my X class into Y class. But I don't think it's very good ... is there a better way to do ?

LarsG · wrote on 2 Dec 2011, 20:28

Maybe if you private inherit Y ?

although I think this faq item presents your problem
http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8

and besides changing your class structure it suggests that virtual inheritance might be a solution.

If you haven't already it might be a very good idea to read that page.

bdajeje · wrote on 2 Dec 2011, 20:45

A private inherit doesn't seems to change anything...

And for the virtual keyword, I already thought about it but I need to be able to write the virtual word in header files. I can write into my Y class but I can't change the QLabel class ....

goetz · wrote on 2 Dec 2011, 22:41

Multiple inheritance from QObject is not supported by Qt

bq. Citation from the "moc documentation":http://doc.qt.nokia.com/4.7/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.

bdajeje · wrote on 2 Dec 2011, 22:58

Thank you Volker :(
It's really a shame ...

goetz · wrote on 2 Dec 2011, 23:04

No, it's a good thing™.
Multiple inheritance in general is problematic, and one should avoid it if possible.

Is i really necessary that your object Y is a QObject based class? Do you need the QObject features (signals, slots, properties)?

bdajeje · wrote on 2 Dec 2011, 23:10

Actually I upgrade some Widget like QLabel, QLineEdit, QSpinBox etc with some new features for myself.
To do that i would create a new class, like Y class, with my new features inside.

Example: I have a class MyQLabel which inherited QLabel and my Y class.
But I can't put, like you said, signals, slots, properties inside it.

andre · wrote on 3 Dec 2011, 08:29

Not sure what you are adding, but perhaps you can do what you want using a charm pattern? I have written a series of such widget extensions that way, and it works quite nicely.

fluca1978 · wrote on 3 Dec 2011, 11:54

[quote author="bdajeje" date="1322867452"]
Example: I have a class MyQLabel which inherited QLabel and my Y class.
But I can't put, like you said, signals, slots, properties inside it.
[/quote]

Inheritance is a very strong coupling. You should consider using composition and/or delegation. You can probably achieve the same result with a simple code.

@Andre
what is the charm pattern?

bdajeje · wrote on 3 Dec 2011, 16:41

Thank you guys for your answers.
Andre to answer your question I'm adding new stuff like animations to my widget.
But sorry guys I don't know what is a charm pattern or even composition and/or delegation.

andre · wrote on 3 Dec 2011, 16:50

[quote]What is the charm pattern?[/quote]

Perhaps that indeeds needs a bit of explanation. In the past, there have been examples of classes that added certain behaviour to a widget. A good example is the "FlickCharm":http://labs.qt.nokia.com/2008/11/15/flick-list-or-kinetic-scrolling/ that demonstrates adding kinetic scrolling to scroll area's. The pattern shown there can be applied much more broadly. There are many other things you can achieve in much the same way.

The basic idea is that you create a class, typically a QObject-derived class, that "magically" adds functionality to another object. That is: not through subclassing, but by instantiating a new object that manipulates how the widget looks or works. You can use things like event filters to make them work. I write them in a way that they manage their own life time, by making themselves children of the object they are supposed to act on. Futhermore, I usually make the constructor private, and create a static method like this:
@static MyCharm* MyCharm::cast(QWidget* subject) ;
@

that you use to create the charm. That allows tricks like making sure that there is only one instance of the charm in question for a single subject widget.

Working this way is quite a powerful programming pattern. It allows you to change the behavior in lots of little but very useful ways, without subclassing. The charm can often apply to multiple types of widgets, and it prevents an explosion of derived types.

Examples of charms I have written, are:

A charm to enable verifying of the contents of tabs before allowing a tab change in QTabBar or QTabWidget
A charm to make it possible to rename tabs of QTabBar or QTabWidget
A charm to add small inline command buttons inside or outside a QLineEdit or a QComboBox. You can cast this charm multiple times to add multiple buttons.
A charm to make the selection list of a QComboBox wrap around.

For this way of programming, Qt offers some very powerful tools to make this possible, especially the event filter. I call this the charm pattern.