Understanding the exposition of Alexandrescu about the weaknesses of multiple inheritance [closed]

Question

UPDATE: I have asked a narrower question here.

On pages 6-7 of Modern C++ Design, Andrei Alexandrescu gives a very fundamental discussion of the strengths and weaknesses of two C++ language features -- multiple inheritance and templates -- with respect to building flexible designs. He concludes:

Now compare the list of drawbacks of multiple inheritance with the list of drawbacks of templates. Interestingly, multiple inheritance and templates foster complementary tradeoffs. Multiple inheritance has scarce mechanics; templates have rich mechanics. Multiple inheritance loses type information, which abounds in templates. Specialization of templates does not scale, but multiple inheritance scales quite nicely. You can provide only one default for a template member function, but you can write an unbounded number of base classes.

I can sense that what Andrei says here is very important, but I cannot really understand what is being said without any examples to illustrate the points. This question is asking to provide simple examples to illustrate these points (please continue reading).

To make the question more specific, I would like to ask to please focus on the weaknesses of multiple inheritance. This is what Andrei has to say about them (the text in square brackets is mine as per my understanding of the context):

In such a setting [i.e. multiple inheritance], [to build a flexible SmartPtr,] the user would build a multithreaded, reference-counted smart pointer class by inheriting some BaseSmartPtr class and two classes: MultiThreaded and RefCounted. Any experienced class designer knows that such a naïve design does not work.

Analyzing the reasons why multiple inheritance fails to allow the creation of flexible designs provides interesting ideas for reaching a sound solution. The problems with assembling separate features by using multiple inheritance are as follows:

1. Mechanics. There is no boilerplate code to assemble the inherited components in a controlled manner. The only tool that combines BaseSmartPtr, MultiThreaded, and RefCounted is a language mechanism called multiple inheritance. The language applies simple superposition in combining the base classes and establishes a set of simple rules for accessing their members. This is unacceptable except for the simplest cases. Most of the time, you need to orchestrate the workings of the inherited classes carefully to obtain the desired behavior.
2. Type information. The base classes do not have enough type information to carry on their tasks. For example, imagine you try to implement deep copy for your smart pointer class by deriving from a DeepCopy base class. But what interface would DeepCopy have? It must create objects of a type it doesn’t knowyet.
3. State manipulation. Various behavioral aspects implemented with base classes must manipulate the same state. This means that they must use virtual inheritance to inherit a base class that holds the state. This complicates the design and makes it more rigid because the premise was that user classes inherit library classes, not vice versa.

I would very much appreciate a simple example for each of the three items above. Each example would show both one limitation of multiple inheritance (e.g. poor mechanics) and how templates do not possess this limitation (Andrei wrote that "multiple inheritance and templates foster complementary tradeoffs").

Kaki

Whoever voted to close the question, please consider providing a comment, so I can improve the question. – Kaki

not one of the close voters, but you can click on close and actually see the reason for closing being "too broad" and actually it is very broad. but interesting non the less. – Piecemeal

this question is much more appropriate for programmers.stackexchange.com – Archiepiscopal

This question has some potential for good answers, I'd be rather disappointed if it were closed. It might be a better fit for programmers.stackexchange though. – Amphithecium

@DavidHaim Asking for examples is no more on-topic at Programmers.SE than it is here. This question would be quickly closed if migrated. – Oneness

I was the first one to vote, but I didn't comment, because of the reason @Alex mentioned. Your question is nice, but it's too broad in my opinion. Notice that I hate the people that downvote, without saying why (as it happened in my answer here: #26716755), sorry for letting you think I was one of them! – Caveman

I thought that by clicking close I would be voting to close my own question, so I did not dare do that :) Thank you for mentioning programmers.stackexchange.com. I did not know about that forum... However, since the question is not closed, I will hope for enlightening replies from the folks here. – Kaki

Hmm... It looks like the question is getting near being closed. Any suggestions how it can be asked not in terms of asking for examples? – Kaki

@MeirGoldenberg: Maybe you can try asking on meta.stackoverflow.com how to phrase the question so that it is not closed (please link to meta in your question in this case). – Amphithecium

@AlexandreC. this question is a poor fit for Programmers - it would be quickly voted down and closed over there, see Why do 'some examples' and 'list of things' questions get closed? Recommended reading: What goes on Programmers.SE? A guide for Stack Overflow – Paralytic

@gnat: I understand this, and I think it is a pity that potentially interesting questions like this one have no place in either site. – Amphithecium

@AlexandreC. "We already tried supporting those questions, we even gave them their own site. Sadly, it didn't work out..." – Paralytic

I have started asking narrower questions on this topic and putting references at the beginning of this post. Hopefully those questions won't be rejected :) – Kaki