Recommended Posts

I just noticed that multiple inheritance get very complicated. Is it worth using? I would think one should use a moderate amount and limit himself. Like so :
class A
{
public :  int a_int;
A() : a_int(0) { }
A(int a) a_int(a) { }
};

class B : public A
{
//implementation omitted

};

class C : public A, protected B
{
//implementation omitted
};
class D : virtual public A, protected C
{
//omitted
};
class E:
{
public :  int a_int;
E() : a_int(0) { }
E(int a) : a_int(a) {  }
};
class F : public B, virtual public E
{
//omitted
}


Although some of these might be redundant its just to prove a point. As you can see it gets really complicated fast. Its hard to keep track sometimes. I have read that some people love it while others hate it. Whats your thoughts from your experiences?

Share on other sites
Any inheritance (multiple or single) should only be used if you're expressing the OO concept of "is a" -- otherwise, the tool you want to use is composition (i.e. member variables).

In my experience, the most common form of MI is the "Java style" of abstract interfaces:
class IFoo {public:  virtual void Foo() = 0;};class IBar {public:  virtual void Bar() = 0;};class Base {public:  Base();  virtual ~Base();};class Derived : public Base, public IFoo, public IBar{public:  Derived();  virtual void Foo();  virtual void Bar();}

Usually interfaces such as IFoo/IBar don't need virtual inheritance, but if you're coding a dreaded-diamond for whatever reason, then you'll need it.

In most cases where private/protected inheritance is used, composition can/should probably be used instead.

Share on other sites
Quote:
 Original post by HodgmanAny inheritance (multiple or single) should only be used if you're expressing the OO concept of "is a" -- otherwise, the tool you want to use is composition (i.e. member variables).In my experience, the most common form of MI is the "Java style" of abstract interfaces:*** Source Snippet Removed ***

So your saying using containment is better than private or protected derived
class? What about when one needs to access protected members from a base class?

Share on other sites
Quote:
 Original post by tnuttySo your saying using containment is better than private or protected derivedclass?
Yes, if your derived class cannot be used in-place of it's base type, then inheritance is wrong.

Private/protected inheritance is a special case of this though, because it expresses "is a" while never allowing derived to be used as a base... so it isn't really inheritance -- it's just composition disguised as inheritance.

Quote:
 What about when one needs to access protected members from a base class?
Protected members are actually part of the "public-interface" of a class, because the details of their implementation are not hidden from the users of the class.
If these members need to be directly modified by other (unrelated) objects, then why not make them public?

Share on other sites
As Hodgman notes, inheritance itself tends to be overused.

Multiple inheritance as it exists in C++ is mostly broken and not worth the effort. In most any type system, it's mostly broken and not worth the effort. That said, I think that is a useful tool for accurately modeling objects in type systems where it's implementation does not resemble the fires of hell.

Share on other sites
You should always use the most appropriate tool for the job, and multiple inheritance is no exception to this. It's just that the range of jobs where MI is the appropriate tool is a fairly small one because composition, singular inheritance and templates/ad-hoc polymorphism are usually much better suited. If you end up dealing with the dreaded-diamond and virtual inheritance then, IMO, you've done something wrong.

Create an account

Register a new account

• Forum Statistics

• Total Topics
628298
• Total Posts
2981890

• 9
• 9
• 11
• 10
• 10