inheritance. Multiple inheritance comes into its own especially when you're living in the real world and often find yourself in the situation of trying to combine libraries from different vendors. This section shows how to avoid the Siamese Twin problem when combining inheritance-based libraries from different vendors. It also demonstrates the many legitimate (and some illegitimate) uses of pure virtual functions, how to code alternatives to multiple inheritance, and how to control who gets to make use of your inheritance relationships.
Item 24. Why Multiple Inheritance?
Difficulty: 6
Some languages, including the SQL99 standard, continue to struggle with the question of whether to support single or multiple inheritance. This Item invites you to consider the issues.
1. What is multiple inheritance (MI), and what extra possibilities or complications does allowing MI introduce into C++?
2. Is MI ever necessary? If yes, show as many situations as you can and argue why MI should be in a language. If no, argue why single inheritance (SI), possibly combined with Java-style interfaces, is equal or superior, and why MI should not be in a language.
Solution
1. What is multiple inheritance (MI), and what extra possibilities or complications does allowing MI introduce into C++?
Very briefly, MI means the ability to inherit from more than a single direct base class. For example:
class Derived : public Base1, private Base2
{
//...
};
Allowing MI introduces the possibility that a class may have the same (direct or indirect) base class appear more than once as an ancestor. A simple example of this is the classic diamond-shaped inheritance graph shape shown in Figure 4.
Here
B
is an indirect base class ofD
twice, once viaC1
and once viaC2
.This situation introduces the need for an extra feature in C++: virtual inheritance. The question at issue is: Does the programmer want
D
to have oneB
base subobject or two? If the answer is one, thenB
should be a virtual base class and Figure 4 becomes the Dreaded Diamond of Death. If the answer is two, thenB
should be a normal (nonvirtual) base class.Finally, the main complication of virtual base classes is that they must be initialized directly by the most-derived class. For more information on this and other aspects of MI, see [Stroustrup00] or [Meyers97] Item 43.
Guideline
Avoid multiple inheritance from more than one non-protocol class (a protocol class means an abstract base class, or ABC, composed entirely of pure virtual functions with no data).
2. Is MI ever necessary?
Short answer: No feature is strictly "necessary" insofar as any program can be written in assembler (or lower). However, just as most people would rather not code their own virtual function mechanism in plain C, in some cases not having MI requires painful workarounds.
So here we have this wonderful feature called MI. The question is, or at least was, is this a Good Thing?[1]
[1] In part, the topic for this Item was inspired by events at the SQL standards meeting in June 1998, when
multiple inheritance was removed from the ANSI SQL99 draft standard. (Those of you who are interested in databases may see a revised form of MI resurrected in SQL4, if/when we get that far.) This was mainly done because the proposed multiple inheritance specification had technical difficulties, and in order to align with languages like Java that do not support true multiple inheritance. Still, just sitting there and listening to people discussing the merits and demerits of multiple inheritance at such a relatively late date was intriguing. It's something we haven't done much in the C++ world since the formative years, and it made me reminisce aloud about extended newsgroup flame wars from years ago (and some more recent than that) with subject lines like "MI is evil!!!"
In short, there are people who think that MI is just a bad idea that should be avoided at all costs. That's not true. Yes, if it's used thoughtlessly, MI can incur unnecessary coupling and complexity. But so does any kind of misused inheritance (see Exceptional C++ [Sutter00] Item 24), and I think we agree that doesn't make inheritance a Bad Thing. And, yes, any program can be written without resorting to MI, but for that matter, any program can be written without using inheritance at all. In fact, any program can be written in assembler. That doesn't mean it's necessarily a good idea or even something you would feel happy about doing.
If yes, show as many situations as you can and argue why MI should be in a language.If no, argue why single inheritance (SI), possibly combined with Java-style interfaces, is equal or superior, and why MI should not be in a language.
So when is MI appropriate? In short, only when each inheritance, taken individually, is appropriate. Exceptional C++ Item 24 presented a fairly exhaustive list of when to use inheritance. Most appropriate real-world uses of MI fall into one of three categories.
1. Combining modules or libraries. I'm citing this point first for a reason, illustrated again below. Many classes are designed to be base classes梩hat is, to use them you are intended to inherit from them. The natural consequence is the question:
What if you want to write a class that extends two libraries, and each library requires you to inherit from one of its classes?
When you're facing this kind of situation, you usually don't have the option of changing the library code to avoid some of the inheritance. You probably purchased the library from a third-party vendor, or maybe it's a module produced by another project team inside your company. Either way, not only can't you change the code, but you may not even have the code! If so, then MI is necessary; there's no other (natural) way to do what you have to do, and using MI is perfectly legitimate.
In practice, I've found that knowing how to use MI to combine vendor libraries is an essential technique that belongs in every C++ programmer's toolchest. Whether you end up using it frequently or not, you should definitely know about it and understand it.
2. Protocol classes (interface classes). In C++, MI's best and safest use is to define protocol classes梩hat is, classes composed of nothing but pure virtual functions. The absence of data members in the base class avoids outright MI's more famous complexities.
Interestingly, different languages/models support this kind of MI through non-inheritance mechanisms. Two examples are Java and COM. Strictly speaking, Java has multiple inheritance, but constrains inheritance of implementation to single inheritance. A Java class can implement multiple "interfaces," where an interface is very similar to a C++ pure abstract base class without data members. COM does not include the concept of inheritance per se (although that's the usual implementation technique for COM objects written in C++), but it likewise has a notion of a composition of interfaces, and COM interfaces resemble a combination of Java interfaces and C++ templates.
3. Ease of (polymorphic) use. Using inheritance to let other code use a derived object wherever a base is expected is a powerful concept. In some cases, it can be very useful to let the same derived object be used in the place of several kinds of bases, and that's where MI comes in. For a good example of this, see [Stroustrup00] section 14.2.2, which demonstrates an MI- based design for exception classes in which a most-derived exception class may have a polymorphic Is-A relationship, with multiple direct base classes.
Note that #3 overlaps greatly with #1 and #2. It's frequently useful to do #3 at the same time as one of the others, and for the same reasons.
One more thing to think about: Don't forget that sometimes it's not necessary to just inherit from two different base classes, but to inherit from each one for a different reason.
"Polymorphic LSP Is-A public inheritance" isn't the only game in town; there are many other possible reasons to use inheritance. For example, a class may need to inherit privately from base class
A
to gain access to protected members of classA
, but at the same time inherit publicly from base classB
to polymorphically implement a virtual function of classB
.Item 25. Emulating Multiple Inheritance
Difficulty: 5
If you couldn't use multiple inheritance, how would you emulate it? This exercise will help you to understand firsthand some of the reasons why multiple inheritance works the way it does in C++. In your answer, don't forget to emulate as natural a syntax as possible for the calling code.
Consider the following example:
class A
{
public:
virtual ~A();
string Name();
private:
virtual string DoName();
};
class B1 : virtual public A
{
string DoName();
};
class B2 : virtual public A
{
string DoName();
};
A::~A() {}
string A::Name(){ { return DoName(); }
string A::DoName() { return "A"; }
string B1::DoName() { return "B1"; }
string B2::DoName() { return "B2"; }
class D : public B1, public B2
{
string DoName() { return "D"; }
};
Demonstrate the best way you can find to "work around" not using multiple inheritance by writing an equivalent (or as near as possible)
class D
without using MI. How would you get the same effect and usability forD
with as little change as possible to syntax in the calling code?* * * * *
Starter: You can begin by considering the cases in the following test harness.