Section 1 - Introduction to Multiple Inheritance

10A.1.1 Overview

This week we begin to wind things up by introducing another advanced topic, multiple inheritance.  Although Java  language designers didn't feel that multiple inheritance was a critical characteristic for a language to possess, C++ designers deemed it useful.  I think you'll agree.

Reading

Multiple Inheritance is not covered in the text, so there is no textbook reading assigned this week.

10A.1.2 Simple Multiple Inheritance

So far, when dealing with inheritance, we have always had only one direct base class for each derived class, i.e., one parent. Still, we could derive many different classes from a single parent, each one expanding or specializing upon the capabilities of the more general base. This is called specialization. As we have seen, it makes a lot of sense and leads to reusable code. The picture is like this:

       Base
	/ \
       /   \
      /     \
     /       \
Derived1    Derived2

Now we consider the opposite: two or more parents for a single derived class:

Base1      Base2
  \         /
   \       /
    \     /
     \   /
      \ /
    Derived

This is called multiple inheritance, and instead of specialization we think of combination. We are combining the functionality of two existing classes into a third.

Useful? Think of it this way. We may have a class which describes products in our company purely from a technical standpoint. It quantifies the engineering specifications of each of these products. Let's call this class EngineeringObject. We may have lots of useful methods to manage this class. Also, there may be another class which is used by material services which treats all of the items in our company as inventory items. There may be an existing class InventoryObject, which is useful for software that purchase, tracks and reports on things from this standpoint.

Now, we want to sell our EngineeringObjects. The tracking capability of the InventoryObject class would be useful, as would the technical information contained in the EngineeringObject class. Let's combine these two (and add some new members like price and targetMarket) and we have the makings of multiple inheritance.

class SalesObject : public EngineeringObject, public InventoryObject
{
    int price;
    char  targetMarket[300];

    // ...
}

That is how it's done. Now, what it means is a trickier question.

Let's start with the fundamental rule: Without frills, and derived as we have done above:

As a consequence, the child class will take up at least as much memory as the two parents combined, plus any of its unique members.The above may seem obvious, but when we think of specific situations it can get sticky.
 

Answer: Too bad. A copy of each member is carried down. The child, as well as the client, if these members are publicly accessible, has to refer to each with the scope resolution operator to disambiguate, as in

Base1::commonName; // (from within a member function)

or

der_obj.Base2::commonName; // (from client).

For other, uniquely named members, this disambiguation is not required, and members are treated as in any class.

Answer: Carefully. Under ordinary circumstances, we know that objects are constructed from most basic to most derived, i.e., from top, down. But with multiple inheritance, there are two or more objects at the same level. The answer comes from the syntax of the derived constructor:

Derived::Derived(  ) : Base1(  ), Base2(  )
{
    // main part of function
}

Since Base1() is to the left of Base2() in this function header, Base1() is called first.

SuperProtoBase
    /   \
   /     \
  /       \
 /         \
Base1    Base2
 \         /
  \       /
   \     /
    \   /
     \ /
   Derived

Answer: The answer to that question is the topic of "Not-So-Simple Multiple Inheritance", the title of the next section.