0

My question is the following. I want to make a new widget which is a QTableWidget + a QMenuBar (with a particular configuration of the QTableWidget). Currently, I have created a MyWidget which derives from QWidget and contains a QTableWidget + a QMenuBar. But is it possible to do the same thing by deriving MyWidget from QTableWidget and QMenuBar? And if it is possible what the constructor looks like?

laurent
  • 88,262
  • 77
  • 290
  • 428
Vincent
  • 57,703
  • 61
  • 205
  • 388

4 Answers4

5

Since both QTableWidget and QMenuBar inherit from QWidget, I strongly recommend not using double inheritance. See, for example this question.

What your doing currently is generally considered the "right" way, at least in Qt. I suspect the main reason you want to use multiple inheritance instead of composition is that you might feel like you have to write a bunch of functions just so that people who are using your widget can, for example, add to the QMenuBar. Such a function might look like this:

QAction *MyWidget::addMenuToMyQMenuBar(QMenu *menu)
{
    return myMenu->addMenu(menu);
}

To me this is a bit silly, and instead I would recommend simply making an accessor function for your QMenuBar:

QMenuBar *MyWidget::menuBar()
{
    return myMenu;
}

Now someone using your class can just do

myWidget->menu()->addAction(someAction);

This style of coding occurs quite commonly in the Qt source code and I consider it much cleaner.

Community
  • 1
  • 1
Anthony
  • 8,570
  • 3
  • 38
  • 46
1

This sounds like composition will suit your needs.

Inheritance satisfies the is-a relationship (NewWidget is a QTableWidget and NewWidget is a QMenuBar?)
Composition satisfies the has-a relationship (NewWidget has a QTableWidget and NewWidget has a QMenuBar?)

Prashant Kumar
  • 20,069
  • 14
  • 47
  • 63
1

It is impossible to inherit from two QWidget's at once. Each QWidget is also a QObject. MOC (Meta-Object compiler) cannot handle such classes.

Rafał Przemysław Malinowski
  • 111
  • 2
0

Inheritance - The relationship is X isa Y

Composition - The relationship is X has a Y

There is your answer - what is the relationship between X and Y?

Ed Heal
  • 59,252
  • 17
  • 87
  • 127
  • It's not that simple. C++ inheritance and classes are designed to sound like "X is like an Y" and not "X is an Y" (that is just a particular case). The real problem, here, is that both the bases have common bases not designed to be shared. Hence composition is the only way to go. But it is a QT designer choice, happened when OOP was the sole way to program classes in C++. – Emilio Garavaglia Jul 21 '12 at 09:28
  • You are just a diamond - see http://en.wikipedia.org/wiki/Diamond_problem. And I agree and that is why Java among others use interfaces to overcome this situation. – Ed Heal Jul 21 '12 at 09:37
  • No, I don't cost that much :-)) Out of irony, May be it is true in certain practice, but the definitions are different: C++ classes can form "diamonds" only if the base is virtual (and a diamond is itself a manageable pattern: may be not the favorite of OOP school, but still manageable it is). That's not how QT was designed. And Java interfaces are just "dimanond facests" as well (simply you don't see that because you don't access the common shared Obejct behind). Just more repetitive to code. How do you inherit (pardon compose) multiple interface IMPLEMENATIONS in java? – Emilio Garavaglia Jul 21 '12 at 10:07
  • Emilio - Java you say that this calls implements X, Y and Y - but at the end of the day there is only one function. – Ed Heal Jul 21 '12 at 10:13
  • The argument is more complex and goes ahead of the purpose of this question. Single inheritance + interfaces does not have the same expressive power of multiple inheritance (but it is "safer" for not enough experienced programmers). The equivalence requires also the implicit forwarding capabilities towards embedded objects. The point is understand what is behind "reusability" of already written code. Interfaces (since don't carry code) are not a good example. But that takes us very far from the original intention.... – Emilio Garavaglia Jul 21 '12 at 11:58
  • My point is just "beware when referring the IS-A and HAS-A methodology", because it is an oversimplification: C++ classes are not the same of OOP objects. They can represent also other things. – Emilio Garavaglia Jul 21 '12 at 11:59