Die Darstellung von Alexandrescu über die Schwächen der Mehrfachvererbung verstehen [geschlossen]

UPDATE: Ich habe eine engere Frage gestellt hier .

Auf den Seiten 6-7 von Modernes C ++ Design gibt Andrei Alexandrescu eine sehr grundlegende Diskussion über die Stärken und Schwächen von zwei C++ Sprachfunktionen - Mehrfachvererbung und Vorlagen - in Bezug auf die Erstellung flexibler Designs. Er schließt:

  

Vergleichen Sie nun die Liste der Nachteile der Mehrfachvererbung mit der Liste der Nachteile von Vorlagen. Interessanterweise fördern Mehrfachvererbung und Templates komplementäre Kompromisse. Mehrfachvererbung hat seltene Mechanik; Vorlagen haben eine reiche Mechanik. Die mehrfache Vererbung verliert die Typinformation, die in den Vorlagen reichlich vorhanden ist. Die Spezialisierung von Vorlagen skaliert nicht, aber die Mehrfachvererbung skaliert ziemlich gut. Sie können nur einen Standardwert für eine Template-Member-Funktion angeben, aber Sie können eine unbegrenzte Anzahl von Basisklassen schreiben.

Ich kann spüren, dass das, was Andrei hier sagt, sehr wichtig ist, aber ich kann nicht wirklich verstehen, was gesagt wird, ohne irgendwelche Beispiele, um die Punkte zu illustrieren. In dieser Frage werden einfache Beispiele zur Veranschaulichung dieser Punkte vorgeschlagen (bitte lesen Sie weiter).

Um die Frage genauer zu formulieren, möchte ich Sie bitten, sich auf die Schwächen der Mehrfachvererbung zu konzentrieren. Dies ist, was Andrei über sie zu sagen hat (der Text in eckigen Klammern gehört mir nach meinem Verständnis des Kontexts):

  

In einer solchen Einstellung [d.h. multiple Vererbung ], [um eine flexible SmartPtr zu erstellen], würde der Benutzer eine Multithread-Smart-Pointer-Klasse mit Referenzzählung erstellen, indem er eine BaseSmartPtr -Klasse und zwei Klassen erbt: MultiThreaded und% Code%. Jeder erfahrene Klassen-Designer weiß es   dass solch ein naives Design nicht funktioniert.

     

Analysieren der Gründe, warum die Mehrfachvererbung die Erstellung von flexibles nicht zulässt   designs liefert interessante Ideen für eine fundierte Lösung. Die Probleme beim Zusammenbau   separate Features durch Mehrfachvererbung sind wie folgt:

     

1. Mechanik . Es gibt keinen Standardcode zum Zusammensetzen der geerbten Komponenten in einem kontrollierten   Weise. Das einzige Tool, das BaseSmartPtr, MultiThreaded und RefCounted kombiniert   ist ein Sprachmechanismus namens Mehrfachvererbung. Die Sprache gilt   einfache Überlagerung in der Kombination der Basisklassen und erstellt eine Reihe von einfachen Regeln   um auf ihre Mitglieder zuzugreifen. Dies ist außer für die einfachsten Fälle inakzeptabel. Die meisten   Von Zeit zu Zeit müssen Sie die Funktionsweise der geerbten Klassen sorgfältig aufeinander abstimmen   Erhalten Sie das gewünschte Verhalten.
  
2. Geben Sie Informationen ein. Die Basisklassen haben nicht genügend Typinformationen, um weiter zu machen   ihre Aufgaben. Stellen Sie sich zum Beispiel vor, Sie versuchen, eine Tiefenkopie für Ihr Smart zu implementieren   Zeigerklasse durch Ableiten von einer DeepCopy-Basisklasse. Aber welche Schnittstelle würde DeepCopy?   haben? Es muss Objekte eines Typs erstellen, den es nicht kennt.
  
3. Staatsmanipulation . Verschiedene Verhaltensaspekte, die mit Basisklassen implementiert werden, müssen manipuliert werden   der gleiche Zustand. Dies bedeutet, dass sie die virtuelle Vererbung verwenden müssen, um ein zu erben   Basisklasse, die den Status enthält. Dies verkompliziert das Design und macht es dadurch steifer   Die Prämisse war, dass Benutzerklassen Bibliotheksklassen erben, nicht umgekehrt.
  

Ich würde ein einfaches Beispiel für jeden der drei obigen Punkte sehr schätzen. Jedes Beispiel würde sowohl eine Einschränkung der Mehrfachvererbung zeigen (zB schlechte Mechanik ) und wie Vorlagen diese Einschränkung nicht besitzen (Andrei schrieb, dass "< em> mehrfache Vererbung und Vorlagen fördern komplementäre Kompromisse ").