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#?

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 ...
–
jcolebrandJan 30 '13 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 :)
–
EarlzJan 30 '13 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.
–
jcolebrandJan 30 '13 at 13:24

2 Answers
2

I thing (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 it's 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):

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:

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't inserted into the single inheritance chain, so it's more like

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.
–
GiorgioJan 30 '13 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 HudecJan 30 '13 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.
–
svickJan 30 '13 at 10:17

@svick: No, it does not. But the alternative is much less efficient as it requires virtual dispatch for member access.
–
Jan HudecJan 30 '13 at 10:49

+1 for a much more complete answer than mine.
–
Nathan C. TreschJan 30 '13 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.

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 BrownJan 30 '13 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.
–
Nathan C. TreschJan 30 '13 at 12:55

@DocBrown As to your assertion that it works in C++, you're mistaken. Namespace collision is a real issue. Name magling mitigtates that, I'm given to understand, but it's not 100%.
–
Nathan C. TreschJan 30 '13 at 12:58

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 BrownJan 30 '13 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
–
Nathan C. TreschJan 30 '13 at 14:06