What is the exact problem with multiple inheritance?

by

The most obvious problem is with function overriding.

Let’s say have two classes A and B, both of which define a method doSomething. Now you define a third class C, which inherits from both A and B, but you don’t override the doSomething method.

When the compiler seed this code…

C c = new C();
c.doSomething();

…which implementation of the method should it use? Without any further clarification, it’s impossible for the compiler to resolve the ambiguity.

Besides overriding, the other big problem with multiple inheritance is the layout of the physical objects in memory.

Languages like C++ and Java and C# create a fixed address-based layout for each type of object. Something like this:

class A:
    at offset 0 ... "abc" ... 4 byte int field
    at offset 4 ... "xyz" ... 8 byte double field
    at offset 12 ... "speak" ... 4 byte function pointer

class B:
    at offset 0 ... "foo" ... 2 byte short field
    at offset 2 ... 2 bytes of alignment padding
    at offset 4 ... "bar" ... 4 byte array pointer
    at offset 8 ... "baz" ... 4 byte function pointer

When the compiler generates machine code (or bytecode), it uses those numeric offsets to access each method or field.

Multiple inheritance makes it very tricky.

If class C inherits from both A and B, the compiler has to decide whether to layout the data in AB order or in BA order.

But now imagine that you’re calling methods on a B object. Is it really just a B? Or is it actually a C object being called polymorphically, through its B interface? Depending on the actual identity of the object, the physical layout will be different, and its impossible to know the offset of the function to invoke at the call-site.

The way to handle this kind of system is to ditch the fixed-layout approach, allowing each object to be queried for its layout before attempting to invoke the functions or access its fields.

So…long story short…it’s a pain in the neck for compiler authors to support multiple inheritance. So when someone like Guido van Rossum designs python, or when Anders Hejlsberg designs c#, they know that supporting multiple inheritance is going to make the compiler implementations significantly more complex, and presumably they don’t think the benefit is worth the cost.

More Related Contents:

  1. A use for multiple inheritance?
  2. Why doesn’t Rust support trait object upcasting?
  3. Inheritance vs. Aggregation [closed]
  4. Java Multiple Inheritance
  5. Constructors vs Factory Methods [closed]
  6. Why would I want to use Interfaces? [closed]
  7. HAS-A, IS-A terminology in object oriented language
  8. Functional programming vs Object Oriented programming [closed]
  9. Explanation of the UML arrows
  10. What is the rationale behind having companion objects in Scala?
  11. Where do I use delegates? [closed]
  12. What is the dependency inversion principle and why is it important?
  13. Difference Between Cohesion and Coupling
  14. Do write-only properties have practical applications?
  15. Polymorphism – Define In Just Two Sentences [closed]
  16. DDD – the rule that Entities can’t access Repositories directly
  17. Are Polymorphism , Overloading and Overriding similar concepts? [closed]
  18. If-less programming (basically without conditionals) [closed]
  19. Are there any rules for OOP?
  20. When to implement an interface and when to extend a superclass?
  21. Mixin vs inheritance
  22. Does the Single Responsibility Principle work in OOP?
  23. What does ‘low in coupling and high in cohesion’ mean
  24. Learning/Implementing Design Patterns (For Newbies) [closed]
  25. Constructors in Go
  26. Coupling, Cohesion and the Law of Demeter
  27. When to use delegation instead of inheritance? [closed]
  28. How do you explain OO to new programmers? [closed]
  29. Multiple Inheritance in java
  30. Aspect Oriented Programming vs. Object-Oriented Programming

Leave a Comment