I'm not a C++ guy, but I'm forced to think about this. Why is multiple inheritance possible in C++, but not in C#? (I know of the diamond problem, but that's not what I'm asking here). How does C++ resolve the ambiguity of identical method signatures inherited from multiple base classes? And why is the same design not incorporated into C#?

  • 3
    For the sake of completeness, what is the "diamond problem" please?
    – jcolebrand
    Jan 30, 2013 at 6:01
  • 1
    @jcolebrand en.wikipedia.org/wiki/Multiple_inheritance see Diamond problem
    – l46kok
    Jan 30, 2013 at 6:20
  • 1
    Sure, I googled it, but how do I know that that is what Sandeep means? If you're going to reference something by an obscure name, when "Multiple inheritance with a shared common ancestor" is more direct ...
    – jcolebrand
    Jan 30, 2013 at 6:24
  • 1
    @jcolebrand I edited it to reflect what I got from the question. I assume he means the diamond problem referenced on wikipedia from the context. Next time drop the friendly comment, AND use the shiny new suggested edit tool :)
    – Earlz
    Jan 30, 2013 at 7:43
  • 1
    @Earlz that only works when I understand the reference. Otherwise I'm making a bad edit, and that's just bad juju.
    – jcolebrand
    Jan 30, 2013 at 13:24

2 Answers 2


Why is multiple inheritance possible in C++, but not in C#?

I think (without having hard reference), that in Java they wanted to limit the expressiveness of the language to make the language easier to learn and because code using multiple inheritance is more often too complex for its own good than not. And because full multiple inheritance is a lot more complicated to implement, so it simplified the virtual machine a lot too (multiple inheritance interacts especially badly with garbage collector, because it requires keeping pointers into the middle of object (at the beginning of the base))

And when designing C# I think they looked at Java, saw that full multiple inheritance indeed wasn't missed much and elected to keep things simple as well.

How does C++ resolve the ambiguity of identical method signatures inherited from multiple base classes?

It does not. There is a syntax to call base class method from specific base explicitly, but there is no way to override only one of the virtual methods and if you don't override the method in the subclass, it's not possible to call it without specifying the base class.

And why is the same design not incorporated into C#?

There is nothing to incorporate.

Since Giorgio mentioned interface extension methods in comments, I'll explain what mixins are and how they are implemented in various languages.

Interfaces in Java and C# are limited to declaring methods only. But the methods have to be implemented in each class that inherits the interface. There is however large class of interfaces, where it would be useful to provide default implementations of some methods in terms of others. Common example is comparable (in pseudo-language):

mixin IComparable {
    public bool operator<(IComparable r) = 0;
    public bool operator>(IComparable r) { return r < this; }
    public bool operator<=(IComparable r) { return !(r < this); }
    public bool operator>=(IComparable r) { return !(r > this); }
    public bool operator==(IComparable r) { return !(r < this) && !(r > this); }
    public bool operator!=(IComparable r) { return r < this || r > this; }

Difference from full class is that this can't contain any data members. There are several options for implementing this. Obviously multiple inheritance is one. But multiple inheritance is rather complicated to implement. But it's not really needed here. Instead, many languages implement this by splitting the mixin in an interface, which is implemented by the class and a repository of method implementations, that are either injected into the class itself or an intermediate base class is generated and they are placed there. This is implemented in Ruby and D, will be implemented in Java 8 and can be implemented manually in C++ using the curiously recurring template pattern. The above, in CRTP form, looks like:

template <typename Derived>
class IComparable {
    const Derived &_d() const { return static_cast<const Derived &>(*this); }
    bool operator>(const IComparable &r) const { r._d() < _d(); }
    bool operator<=(const IComparable &r) const { !(r._d() < _d(); }

and is used like:

class Concrete : public IComparable<Concrete> { ... };

This does not require anything to be declared virtual as regular base class would, so if the interface is used in templates leaves useful optimization options open. Note, that in C++ this would probably still be inherited as second parent, but in languages that don't allow multiple inheritance it's inserted into the single inheritance chain, so it's more like

template <typename Derived, typename Base>
class IComparable : public Base { ... };
class Concrete : public IComparable<Concrete, Base> { ... };

The compiler implementation may or may not avoid the virtual dispatch.

A different implementation was selected in C#. In C# the implementations are static methods of completely separate class and the method call syntax is appropriately interpreted by compiler if a method of given name does not exist, but an "extension method" is defined. This has the advantage that extension methods can be added to already compiled class and the disadvantage that such methods can't be overriden e.g. to provide optimized version.

  • One might want to mention that multiple inheritance will be introduced into Java 8 with interface extension methods.
    – Giorgio
    Jan 30, 2013 at 9:10
  • @Giorgio: No, multiple inheritance will definitely not be introduced in Java. Mixins will be, which is very different thing, though it covers many remaining reasons to use multiple inheritance and most reasons to use curiously recurring template pattern (CRTP) and works mostly like CRTP, not like multiple inheritance at all.
    – Jan Hudec
    Jan 30, 2013 at 9:42
  • I think multiple inheritance doesn't require pointers into middle of an object. If it did, multiple interface inheritance would also require it.
    – svick
    Jan 30, 2013 at 10:17
  • @svick: No, it does not. But the alternative is much less efficient as it requires virtual dispatch for member access.
    – Jan Hudec
    Jan 30, 2013 at 10:49
  • +1 for a much more complete answer than mine. Jan 30, 2013 at 12:56

The answer is that it doesn't work correctly in C++ in the event of namespace clashes. See this. To avoid namespace clashing you have to do all kinds of gyrations with pointers. I worked at MS on the Visual Studio team and I at least in part the reason they developed delegation was to avoid namespace collision altogether. Preiouvsly I had said that they also considered Interfaces to be part of the multiple inheritance solution, but I was mistaken. Interfaces are actuallly amazing and can be made to work in C++, FWIW.

Delegation specifically addresses namespace collision: You can delegate to 5 classes and all 5 of them will export their methods to your scope as first class members. On the outside looking in this IS multiple inheritance.

  • 1
    I find it very unlikely that this was the primary reason for not to include MI in C#. Furthermore, this post does not answer the question why MI works in C++ when you don't have "namespace clashes".
    – Doc Brown
    Jan 30, 2013 at 12:07
  • @DocBrown I worked at MS on the Visual Studio team and I assure you that's at least in part the reason they developed delegation and interfaces, to avoid namespace collision altogether. As to the quality of the question, meh. Use your downvote, others seem to think that it's useful. Jan 30, 2013 at 12:55
  • 1
    I have no intention to downvote your answer since I think it is a correct one. But your answer pretends MI is completely unusable in C++, and that's the reason they did not introduce it in C#. Though I don't like MI very much in C++, I think it is not completely unuasable.
    – Doc Brown
    Jan 30, 2013 at 14:04
  • 1
    It's one of the reasons, and I didn't mean to imply that it doesn't ever work. When something is non-deterministic in computing I tend to say it's "broken", or that it "doesn't work" when I intend to mean "it's like voodoo, it may or may not work, light your candles and pray." :D Jan 30, 2013 at 14:06
  • 1
    are "namespace collisions" non-deterministic?
    – Doc Brown
    Jan 30, 2013 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.