17.9 — Multiple inheritance

So far, all of the examples of inheritance we’ve presented have been single inheritance -- that is, each inherited class has one and only one parent. However, C++ provides the ability to do multiple inheritance. Multiple inheritance enables a derived class to inherit members from more than one parent.

Let’s say we wanted to write a program to keep track of a bunch of teachers. A teacher is a person. However, a teacher is also an employee (they are their own employer if working for themselves). Multiple inheritance can be used to create a Teacher class that inherits properties from both Person and Employee. To use multiple inheritance, simply specify each base class (just like in single inheritance), separated by a comma.

Problems with multiple inheritance

While multiple inheritance seems like a simple extension of single inheritance, multiple inheritance introduces a lot of issues that can markedly increase the complexity of programs and make them a maintenance nightmare. Let’s take a look at some of these situations.

First, ambiguity can result when multiple base classes contain a function with the same name. For example:

When c54G.getID() is compiled, the compiler looks to see if WirelessAdapter contains a function named getID(). It doesn’t. The compiler then looks to see if any of the parent classes have a function named getID(). See the problem here? The problem is that c54G actually contains TWO getID() functions: one inherited from USBDevice, and one inherited from NetworkDevice. Consequently, this function call is ambiguous, and you will receive a compiler error if you try to compile it.

However, there is a way to work around this problem: you can explicitly specify which version you meant to call:

While this workaround is pretty simple, you can see how things can get complex when your class inherits from four or six base classes, which inherit from other classes themselves. The potential for naming conflicts increases exponentially as you inherit more classes, and each of these naming conflicts needs to be resolved explicitly.

Second, and more serious is the diamond problem, which your author likes to call the “diamond of doom”. This occurs when a class multiply inherits from two classes which each inherit from a single base class. This leads to a diamond shaped inheritance pattern.

For example, consider the following set of classes:

Scanners and printers are both powered devices, so they derived from PoweredDevice. However, a copy machine incorporates the functionality of both Scanners and Printers.

There are many issues that arise in this context, including whether Copier should have one or two copies of PoweredDevice, and how to resolve certain types of ambiguous references. While most of these issues can be addressed through explicit scoping, the maintenance overhead added to your classes in order to deal with the added complexity can cause development time to skyrocket. We’ll talk more about ways to resolve the diamond problem in the next lesson.

Is multiple inheritance more trouble than it’s worth?

As it turns out, most of the problems that can be solved using multiple inheritance can be solved using single inheritance as well. Many object-oriented languages (eg. Smalltalk, PHP) do not even support multiple inheritance. Many relatively modern languages such as Java and C# restrict classes to single inheritance of normal classes, but allow multiple inheritance of interface classes (which we will talk about later). The driving idea behind disallowing multiple inheritance in these languages is that it simply makes the language too complex, and ultimately causes more problems than it fixes.

Many authors and experienced programmers believe multiple inheritance in C++ should be avoided at all costs due to the many potential problems it brings. Your author does not agree with this approach, because there are times and situations when multiple inheritance is the best way to proceed. However, multiple inheritance should be used extremely judiciously.

As an interesting aside, you have already been using classes written using multiple inheritance without knowing it: the iostream library objects std::cin and std::cout are both implemented using multiple inheritance!


Avoid multiple inheritance unless alternatives lead to more complexity.

17.x -- Chapter 17 comprehensive quiz
17.8 -- Hiding inherited functionality

26 comments to 17.9 — Multiple inheritance

  • crolis

    Maybe I missed it, but is everything inheritable inherited all inclusively all the time or can you pick and choose?

    class A_Bazzillion_Public_Things
    // I have a bazzillion public things

    class Six_Things_Of_Yours : A_Bazzillion_Public_Things
    // I only want 6 of your public things, or do I have to take them all?

    Clearly I'm new to inheritance, but I have 2 classes which of each have many public things. However, I only want 1 from one and 2 from the other. I'm not sure how to look "under the hood" and discover stack/heap allocation (which might be a good thing because if I did, I'd do that literally for everything burning a lot of time :-/ ... damn, now I want to know. Do you know?)

    • Alex

      Inheritance is all or nothing. You can change the access level of various members though, so you could inherit everything and then hide the stuff you don't want.

      If you want to do something like what you're suggesting, I question whether inheritance is really the right model. You might be better off with either a composition class or a new class entirely.

      • crolis

        Thank you Alex. I'm using (or might not now) an Arduino library that has a lot of public things. I guess if I ever write my own little library I should be more cautious of what is public.

  • TimCook

    >>There are many issues that arise in this context, including whether Copier should have one or two copies of PoweredDevice
    Would you explain what you meant by the sentence above? What doe you mean by 'whether Copier should have one or two copies of PoweredDevice'?

  • Banshee

    Hi, I believe the last line (rule) should be enclosed with a gray or green box to make it stand out and easier to read. Other lessons follow this design.

    "Rule: Avoid multiple inheritance unless alternatives lead to more complexity."

  • koe

    Hi, code tags on this page also appear to be broken (alongside 11.6b).


    what is syntax of diamond problems?

    • P. Lam

      Does this answer your question?

      • Constant_n

        No. It doesn't illustrate the "diamond" problem. It's the same without the class A:

        I'd rather write it this way:

  • Hi Alex,

    Hope you don't mind readers pointing out typos :)

    >> you have already been using classes written using multiple "inherited"

  • Omri

    "Many relatively modern languages such as Java and C# restricts classes to single inheritance of normal classes..."
    "Many relatively modern languages such as Java and C# *restrict* classes to single inheritance of normal classes..."

  • Frane

    Hi Alex,
    First of all thank you for this tutorial it is perfect and help me a lot (still is).
    I just notice one small typo I have encountered.
    the member variable is defined without n (m_teachesGrade)

    Keep up the good work and thank you once again.
    BR from Split, Croatia,

  • Albert

    Hey Alex, might want to s/adaptor/adapter...

    Otherwise, very useful post. I appreciate this site a lot.

  • Trey

    Does this course talk about inheritance like:

  • Darren

    So in the first example of multiple inheritance a Teacher is-a Person but is also an Employee. However, an Employee is not a Person? How very totalitarian of you Alex!

  • May be I have made some silly mistakes here, but I can't figure it out:

    Compiler throws 7 errors and all of them live inside overloaded operator (<<) function. What's bad?

    • Alex

      You've declared para as a const, but the functions it accesses (p_name(), p_age(), etc...) are not const. It's really complaining about a const mismatch.

      Best practice here would be to make all of the get accessor functions const. You should also make para a reference so it avoids making a copy when the function is called.

  • pranavjain02.89

    Just a quick note about the order of the constructor to be called in case of multiple inheritance.

    It will always be from left to right during derived class declaration.Irrespective of the order of the constructor called during initializer list.

    For exercise try this

Leave a Comment

Put all code inside code tags: [code]your code here[/code]