Here I include an answer I have given recently on one of such forums, as I find it to be useful for other devs.
Let’s not confuse (multiple) implementation inheritance, which is what C++ has, and (multiple) Interface Inheritance, which is what Java and C# have.
C++ does not have interfaces, but it does have abstract classes.
One of the reasons why abstract classes exist in C++ is to be able to do what interfaces do for Java and C#.
So, just as it is necessary to allow for multiple interface inheritance, C++ must support multiple implementation inheritance to be able to use abstract classes as interfaces and to have multiple “interface” inheritance (with abstract classes) just like Java and C# have.
Why is it necessary to allow for multiple interface inheritance?
Well, to find a short and simple way to explain this requires some pattern thinking.
Let’s suppose that we have a certain class that participates in a few mechanisms or design patterns.
In each mechanism, that class will have its own role in the society of classes that participate in the pattern.
So, the same class will have a set of roles, on each role will have to comply to the semantics of the mechanism it belongs to.
Each set of semantics will be formed by public methods and properties.
Each one of these sets of public methods and properties is an interface of that class, and to be useful, it has to be a member of each of the mechanisms it participates in.
As we all know, the way to make software architecture possible is to allow for components that contain classes that could work as interchangable parts: weak coupling!
But to have a simple way to implement that weak coupling, we need interfaces (or it’s sibling: abstract classes).
As you see, there is a clear requirement for multiple interface inheritance.
If we care to analyze most Application Frameworks done over the years for C++, we may find the unexpected surprise that they do not use multiple implementation inheritance with concrete classes, and they just use it with abstract classes.
It does make sense to question why would companies like Borland and Microsoft did not use a good thing like multiple implementation inheritance with concrete classes?
Well, we could argue a few possible answers, but I could guess that the simplest answer would suffice: multiple implementation inheritance with concrete classes is not practical, out of being too complex, beyond the trivial code samples.
Application Frameworks are really complex beasts on their own right.
Another idea that we could entertain as an explanation is coupling: we try that our architectures use as much weak coupling as possible, and just to be very clear, we are talking about decoupling dependencies between concrete classes.
One way to achieve that is with interface inheritance, which in C++, it is called “implementation inheritance with abstract classes”.
Well, if we were to follow this principle, it does not make much sense to use multiple implementation inheritance with concrete classes, as it increases dependencies between concrete classes, which is the opposite effect of the principle.
Over the years, I have read a few times a question similar to the following:
If Java and C# also support abstract classes like C++ does, why don’t they also support multiple implementation inheritance?
Well, the truth is that multiple interface inheritance, support of abstract classes and single implementation inheritance is a much better solution for the inheritance paradigm that just multiple implementation inheritance with support of abstract classes.
Both Java and C# architects and developers can’t go wrong with their abstractions, as the possibility to make that mistake is avoided from the start, while that is not the case with C++.