9. Multiple Inheritance Table of Contents: 9. Multiple Inheritance.................................................................. 9-1 Multiple inheritance is where a class inherits features from more 9.1 Introduction to MI.......................................................................................... 9-2 than one parent class. In addition to providing the derived class 9.2 Introduction to C++ MI ................................................................................. 9-5 9.3 Disambiguating Members.............................................................................. 9-6 with a wide set of features, this allows the resulting derived class 9.3.1 Disambiguating Member Functions.................................................. 9-6 to behave as if it was either parent class when upcast! 9.3.2 Dominance ........................................................................................ 9-7 Multiple inheritance, in its simplest form, is not hard to 9.3.3 Disambiguating Member Attributes.................................................. 9-7 9.4 Upcasting In The Presence of MI.................................................................. 9-8 understand, use, or implement. But by its very nature, multiple 9.5 Diamonds and Virtual Base Classes ............................................................. 9-9 inheritance can in practice get very messy, complex, and for 9.5.1 Diamond Inheritance Patterns........................................................... 9-9 compiler writers complicated, inefficient, and bug prone to 9.5.2 Virtual Base Classes........................................................................ 9-10 implement. And in many cases, it has been used by 9.5.3 Multiple Triggering of Constructors............................................... 9-11 programmers and library vendors as an inappropriate mechanism 9.6 Summary ....................................................................................................... 9-12 for mixing together of features. It has thus got a poor reputation. 9.7 References ..................................................................................................... 9-14 It probably deserves this reputation as it is rarely necessary in languages that don’t lack other compensating features. Readings: [Optional] The sub-section titled Multiple Inheritance in Chapter 14 of [Prata2002]. Copyright 1997 by R. Tront 9-1 Copyright 1997 by R. Tront 9-2 9.1 Introduction to MI classes, and in many cases is not the best way. As a result, many good OO languages do not have MI. Here is an example of multiple inheritance: • One of the most well known and widely used OO languages, Smalltalk, does not have MI. • Modula-3 does not have MI. WindowWith Menu WindowWithBorder • ADA95 does not have MI. There is a section of the design rational for ADA95 originally from [Taft95] that examines the major 3 reasons you might want to mix classes. It then shows how all three can be done more elegantly, appropriately, or efficiently using the other features of ADA95. To see it, browse http://wuarchive.wustl.edu/languages/ada/userdocs/ rat106/rat_cont.htm, and select section II.4.6. Unfortunately, MI is not often the best way to mix the features of two classes together. But if a language does not have other ways of merging the features of two classes together, MI was WindowWithMenuAndBorder sometimes added as a way to do this. For instance: • MI is used in the very OO language Eiffel, as that language As shown in [Prata95], it is easy and straight forward to declare lacks a good way to import another module’s features. In fact, and use multiple inheritance. Here is the basic C++ syntax: it has little concept of modules. Instead, it simply inherits from any and all classes to provide a new class with the features you class SingingWaiter : public Waiter, public Singer { want. //added attributes. //added methods. • C++ had the #include and linker facilities to import features //overridden methods. from other modules and classes into a program. But this alone }; is not adequate. MI was added to C++ in Version 2 of the That is not so hard to comprehend. The idea is that you want to language to provide more class-specific mixing of features. mix together the features of two classes into a resulting derived Unfortunately, this was done before the C++ community class. That is not so bad. appreciated other alternative language facilities that would provide this same functionality. One of these other alternatives MI was originally an academic curiosity that was recognized to was nested classes (i.e. member attributes which are classes nicely model the concept of an IS-A relationship which occurs themselves), which model a class ‘having’ features of several when an instance could be a member of several unrelated classes (rather than ‘IS-A”). With proper nested classes (that classes. Sometimes being able to model/mix two classes as were automatically constructed, copied, and destructed), a parents is very important. But MI is not the only way to mix two Copyright 1997 by R. Tront 9-3 Copyright 1997 by R. Tront 9-4 class could elegantly have aspects of several classes. In many 9.2 Introduction to C++ MI cases of MI, the subclass IS not A subclass of its parent, it only HAS a parent. e.g. Is a window a rectangle, or does it just The example shown above, and repeated here: HAVE a set of coordinates for specifying a rectangle. For a class SingingWaiter : public Waiter, public Singer { discussion of composition vs. (even single) inheritance, see the //added attributes. “Choosing Composition vs. Inheritance” sub-section of //added methods. Chapter 12 of [Eckel95]. Nested classes were not added until //overridden methods. Version 4 of the C++ language. }; • C++ also lacked generic/parameterized/template classes at the illustrates straight forward declaration of MI. time MI was added. These have been present in ADA since We have already covered how base classes are handled. 1983, but their mixing power seems to have been long unappreciated by the C++ community. The template feature • Their public methods can be invoked by clients of the derived was finally added to C++ also in Version 4. Note that class. templates are often more efficient in time and space than • Their attributes can be referred to if public. multiple inheritance. • Their constructors, operators, and destructors can be manually Now that C++ has nested classes and templates, even the chained to, and are even often automatically chained to. designer of C++, if I recall [Stroustrup94] correctly, wishes MI Basically, these same things happen to the multiple base classes had not been added. There are some people who feel MI should of an MI derived class. There is not a lot more to say about the be removed from C++. Unfortunately, this is impractical. simple application of MI. It is the problems and complications Though not a lot of MI code has been written, it would be of MI which need attention. terrible to change C++ so that version 3 and earlier syntax no longer worked. On the other hand, many major vendor container libraries, such as those from Microsoft and Borland, have recently been re- written. Templates are so superior to MI for implementing containers (e.g. container classes whose job was to store other class instances) that both the vendors and the users of these libraries haven’t minded the disruptive change. Unfortunately, these vendors now have to support both their old MI container libraries and the new templatized ones. Copyright 1997 by R. Tront 9-5 Copyright 1997 by R. Tront 9-6 9.3 Disambiguating Members 9.3.2 Dominance Another way to avoid this problem is, as the derived class 9.3.1 Disambiguating Member Functions programmer, manually override both the init() members of the The first messy complication you run into with inheritance is bases, and define one specifically for MIClass. This actually inheriting from parents that both have a member function with introduces a third version of init()! But C++ will consider the the same name. (This can also occur if the inheritance is from third one introduced via overriding in the derived class as one parent and from a grandparent on the other side of the ‘dominant’, and thus: family.) As an example of the former, consider: myMIInstance.init(); class Base1 { will invoke MIClass::init(). public: int init(); You must be careful as a client programmer when dominant }; class Base2 { functions are present in a complex (virtual) inheritance public: hierarchy, as it easy to see a function called init() in an upper int init(); class and use it thinking it is the only one which might be }; invoked. In fact, you might be invoking a dominant one further class MIClass : public Base1, public Base2 { //added and overridden members. below that you had not noticed! }; 9.3.3 Disambiguating Member Attributes If a client of MIClass invokes the member function: Ambiguity can also occur if there are identically named myMIInstance.init(); attributes inherited from more than one ancestry. Normally the which of the two init() functions is run? compiler will force you to disambiguate using the scope resolution operator. You might ask why anyone would program three classes this way. But what if your Base1 were supplied by Microsoft, and Base2 by Borland, and you needed to mix the features of the two classes. Because you do not have access to either base classes’ code, you cannot modify the code to avoid this ambiguity. The compiler will normally detect this kind of ambiguity. You