ist die virtuelle Vererbung von rein abstrakten Klassen (Schnittstellen) notwendig

Warum ist es, dass in den folgenden code der compiler beschwert sich, dass PureAbstractBase ist ein Mehrdeutiger base Klasse MultiplyInheritedClass? Ich merke, ich habe zwei Kopien der PureAbstractBase im MultiplyInheritedClass und dass FirstConreteClass und SecondConreteClass abgeleitet werden sollten praktisch, weil Sie in der mittleren Zeile die Raute (und das ist in der Tat das problem zu beheben mit dem code unten). Aber obwohl ich zwei Kopien der Schnittstelle, warum ist es, dass der code in MultiplyInheritedClass nicht einfach überschreiben beiden und eindeutig wählen die interface-Klasse definiert MultiplyInheritedClass?

#include <iostream>
using namespace std;

class PureAbstractBase {
  public:
    virtual void interface() = 0;
};

//I know that changing the following line to:
//class FirstConcreteClass : public virtual PureAbstractBase {
//fixes the problem with this hierarchy
class FirstConcreteClass : public PureAbstractBase {
  public:
    virtual void interface() { implementation(); }
  private:
    void implementation() { cout << "This is object FirstConcreteClass\n"; }
};

//I know that changing the following line to:
//class SecondConcreteClass : public virtual PureAbstractBase {
//fixes the problem with this hierarchy
class SecondConcreteClass : public PureAbstractBase {
  public:
    virtual void interface() { implementation(); }
  private:
    void implementation() { cout << "This is object SecondConcreteClass\n"; }
};

class MultiplyInheritedClass : public FirstConcreteClass,
                               public SecondConcreteClass {
  public:
    virtual void interface() { implementation(); }
  private:
    void implementation() { cout << "This is object MultiplyInheritedClass\n"; }
};

Weiter, warum ich keine Probleme mit der folgenden Hierarchie? Nicht die ConcreteHandler Klasse haben drei Kopien des AbstractTaggingInterface in diesem Fall? Warum also nicht das gleiche Problem wie im obigen Beispiel?

#include <iostream>
using namespace std;

class AbstractTaggingInterface {
  public:
    virtual void taggingInterface() = 0;
};

class FirstAbstractHandler : public AbstractTaggingInterface {
  public:
    virtual void taggingInterface() { cout << "FirstAbstractHandler\n"; }
    virtual void handleFirst() = 0;
};

class SecondAbstractHandler : public AbstractTaggingInterface {
  public:
    virtual void taggingInterface() { cout << "SecondAbstractHandler\n"; }
    virtual void handleSecond() = 0;
};

class ThirdAbstractHandler : public AbstractTaggingInterface {
  public:
    virtual void taggingInterface() { cout << "ThridAbstractHandler\n"; }
    virtual void handleThird() = 0;
};

class ConcreteHandler : public FirstAbstractHandler,
                        public SecondAbstractHandler,
                        public ThirdAbstractHandler {
  public:
    virtual void taggingInterface() = { cout << "ConcreteHandler\n"; }
    virtual void handleFirst() {}
    virtual void handleSecond() {}
    virtual void handleThird() {}
};

Ich versuche, wickeln Sie meinen Kopf herum, dies alles, weil ich hatte ein Gespräch mit einem Kollegen vor kurzem, wo er behauptete, dass, wenn Sie waren Erben von rein virtuellen Klassen (Schnittstellen) ohne Daten-member dann virtuelle Vererbung nicht notwendig war. Ich glaube zu verstehen, warum die alten code-Beispiel funktioniert nicht und die letzteren würden gehen ein langer Weg zu bekommen gerade in meinem Kopf (und klar, was er genau meint mit seinem Kommentar). Vielen Dank im Voraus.

  • Ich weiß nicht, ob ich Ihre Frage verstehe, so könnten Sie das bitte klären? Soweit ich sehen kann, das zweite Beispiel ist nur Moor-standard-Vererbung ohne überraschungen. Das erste Beispiel ist unzureichend definiert, weil Sie multiplizieren Erben mehrdeutig Außerkraftsetzungen, die Sie lösen können mit der virtuellen Vererbung.
  • SB Danke für die Hilfe und sorry für die übereilte downvote (Sie sind jetzt von Ihnen positiv bewertet werden). Ich habe die zweite code-snippet zu gehören überschreibt. Ich bin sicher, dass meine Klarheit-Problem zu tun hat, mit meiner Verwirrung über das Problem. Ich denke, meine Frage ist, wie ist ConcreteHandler in der Lage zu Holen die richtige überschreibung für die taggingInterface Anruf in der Erwägung, dass MultiplyInheritedClass nicht in der Lage ist?
  • Keine sorgen 🙂 Also, was denken Sie, ist die Zweideutigkeit in dem zweiten Beispiel? An welchem Punkt sollte es nicht 100% klar, das überschreiben zu nehmen? Da alle Basis-Funktionen, rein virtuelle, Sie können nicht aufgerufen werden, so dass nur eine einzige Implementierung bleibt. Im ersten Beispiel gibt es mehrere gleich-gültig-Implementierungen. Denken Sie nur an wie ein PureAbstractBase* soll die eigentliche Funktion, die Sie wollen, ohne die notwendigen vtables (die Installation über virtuelle Vererbung).
  • SB Oh ... so der Grund, warum das zweite Beispiel funktioniert, weil ich kann nicht wirklich instanziieren, die eine der Grundlagen Klassen in diesem Fall? Ich kann mir vorstellen, dass bedeutet, dass, wenn ich auch eine der Handler-Funktionen nicht pure-virtual-dies wird auch brechen, genau wie im ersten Beispiel? Ich werde versuchen, und wenn dem so ist, aktualisieren Sie bitte Ihre Antwort zu reflektieren, Ihren Kommentar, und ich werde markieren Sie es als richtig.
  • Probieren Sie es einfach aus. Nehmen Sie mein einfaches Beispiel-code unten, zum Beispiel, und entfernen Sie den "virtual" - keywords und sehen, was der compiler sagt. Es wird alles einkochen, die Möglichkeit zur eindeutigen Bestimmung der richtigen angerufene von einem base-pointer, d.h. A * p = new C; p->foo();. Das Letzte Gespräch muss eindeutig bestimmbar sind, oder sonst erhalten Sie eine Fehlermeldung. (Beachten Sie, dass die Destruktoren müssen aufrufbar sein.)
  • SB Nur versucht haben, entfernen die abstrakte Methode aus einer der handler-Klassen, so dass es nicht rein-virtuelle und es noch kompiliert und druckt, was ich erwarte (ich habe eine triviale main, wo ich instaniate eine ConcreteHandler dynamisch und rufen Sie die tagging-inteface über einen Zeiger). Also ich denke, es gibt noch etwas ich bin nicht ganz immer.
  • Nach dem code, und was Sie erwarten passieren sollte und was tatsächlich passiert. (Halten Sie es minimal und kurz, denke ich.)
  • Sind Sie sicher, dass das erste Beispiel funktioniert nicht bei dir? Ich habe gerade versucht es auf Visual Studio 2008 und es hat sehr gut geklappt, nicht einmal eine Warnung! welchen compiler benutzt du?
  • SB ich denke, dass ich Durcheinander das Beispiel-code, so sieht es aus, wenn ich versuche, Sie zu instanziieren, die meisten abgeleitet, die über einen Zeiger auf die tagging-interface-Klasse beschwert es sich über Mehrdeutigkeit. Hier ist also eine Frage, sollte der zweite code-snippet "arbeiten" oder ist es schlechter code, die werfen compilation errors/warnings je nachdem, wie es verwendet?
  • gcc 4.5.1
  • Im zweiten Ausschnitt ist ziemlich Durcheinander im moment. Sie kann nicht schreiben, " = { }", und Sie falsch "Dritte"/"Dritte". Aber dann bist du immer noch fehlende virtuelle Vererbung! Fügen Sie code zum aufrufen des überschreiben, oder Sie könnten verpassen, die Fehler.
  • ja wie Sie schon in Ihrer Antwort das problem kommt erst, wenn die Anrufe an die Klassen sind aufgerufen, in gewisser Weise.
  • SB habe ich Fix die cut und paste-Fehler, wie Sie vorgeschlagen. Ich denke, dass das Problem genau das, was Sie und andere darauf hin: dass der code nicht kompiliert, wenn es aufgerufen wird, in gewisser Weise. Ich habe versucht, herauszufinden, der Kern etwas komplizierter und ich denke ich bekomme es jetzt: der code nie aufgerufen wird, wird über einen Zeiger auf die Basis so der Anruf ist nie eindeutig und folglich alles kompiliert in Ordnung, obwohl ich jetzt glaube, dass der code falsch ist. Nochmals vielen Dank.
  • SB, stellt sich gleichzeitig die Frage, dass, wenn es nie eine Notwendigkeit zum aufrufen des code auf diese Weise in die "original" - design, war ich versucht, zu umschreiben, dann ist die Vererbung der Rechte design überhaupt?
  • Der compiler ist sicherlich zu optimieren, Weg-features, die nicht verwendet werden, so können Sie manchmal Weg schreiben mehrdeutigen Definitionen, wenn diese nie benötigt werden... so ist es am besten, immer zu schreiben, eine vollständige test-first! (Und nach dem test SO zu zeigen, wie weit Sie schon habe 🙂 .) Als ob die Konstruktion sinnvoll ist, kannst nur du wissen. Wenn Ihre Klassen haben eine gemeinsame Schnittstelle, aber unterschiedliche spezifische Implementierungen, dann Vererbung richtig klingt, aber wenn Sie nie brauchen eine bestimmte Schnittstelle, vielleicht ist etwas falsch mit dem design dort...

InformationsquelleAutor bpw1621 | 2011-06-19
  1. 5

    Müssen Sie die virtuelle Vererbung zu überwinden, die Diamant-Mehrdeutigkeit:

    class FirstConcreteClass  : public virtual PureAbstractBase { ... };
class SecondConcreteClass : public virtual PureAbstractBase { ... };

    Lange-winded Erklärung: Angenommen, Sie haben diese:

    //*** Example with errrors! *** //
struct A { virtual int foo(); };
struct B1 : public A { virtual int foo(); };
struct B2 : public A { virtual int foo(); };
struct C: public B1, public B2 { /* ... */ };  //ambiguous base class A!

int main() {
  A * px = new C;                              //error, ambiguous base!
  px->foo();                                   //error, ambiguous override!
}

    Die Vererbung von der virtuellen Funktion foo ist zweideutig, denn es kommt in drei Arten: aus B1 von B2 und von A. Die erbschaft-Diagramm bildet ein "Diamant":

       /-> B1 >-\
A->          ->C
   \-> B2 >-/

    Durch die Vererbung virtuelle struct B1 : public virtual A; etc., ermöglichen Sie jedem baseclass von C* zu nennen, die richtige Mitglied:

    struct A { virtual int foo(); };
struct B1 : public virtual A { virtual int foo(); };
struct B2 : public virtual A { virtual int foo(); };
struct C: public B1, public B2 { virtual int foo(); };

    Wir muss auch definieren C::foo() für diesen Sinn zu machen, da sonst C würde nicht über ein klar definiertes Mitglied foo.

    Einige weitere details: nehmen wir an, wir haben jetzt eine richtig praktisch-Erben-Klasse C wie oben. Wir können den Zugriff auf alle der verschiedenen virtuellen Mitglieder wie gewünscht:

    int main() {
  A * pa = new C;
  pa->foo();      //the most derived one
  pa->A::foo();   //the original A's foo

  B1 * pb1 = new C;
  pb1->foo();     //the most derived one
  pb1->A::foo();  //A's foo
  pb1->B1::foo(); //B1's foo

  C * pc = new C;
  pc->foo();      //the most derived one
  pc->A::foo();   //A's foo
  pc->B1::foo();  //B1's foo
  pc->B2::foo();  //B2's foo
  pc->C::foo();   //C's foo, same as "pc->foo()"
}

     

    Update: Wie David sagt im Kommentar, der wichtige Punkt hier ist, dass die intermediate-Klassen B1 und B2 Erben praktisch, so dass weitere Klassen (in diesem Fall C) können Erben vom Sie, während gleichzeitig halten Sie die Vererbung aus A eindeutig. Sorry für die anfänglichen Fehler und danke für die Korrektur!

    • Bitte Lesen Sie die gesamte Frage: ich weiß, wie fix das erste Beispiel, wie ich klar dargelegt. Ich will wissen, warum das zweite Beispiel nicht leiden unter dem gleichen Problem das erste Beispiel tut.
    • Hast du nur vote mich down ohne das Verständnis, die Erklärung? (Die könnte ich ausbauen, wenn Sie erzählen Sie mir nicht aus unnötig?) Das problem entsteht nur, wenn die virtuelle Funktion ist außer Kraft gesetzt, die von den abgeleiteten Klassen, d.h. wenn die abgeleiteten Klassen definieren Sie Funktionen mit dem gleichen Namen und Signatur. Dein zweites Beispiel hat keine Funktionen überschrieben!
    • Wenn ich eine überschreibung der taggingInterface in jedem der iHandler Klassen das Beispiel noch kompiliert einwandfrei. Ich nehme meine nach unten zu Stimmen, weil Sie versuchen, hilfsbereit zu sein und ich meine nicht zu hart sein/Ausschlag. Es war die zweite Antwort, die offenbar nicht auf die Frage.
    • Downvoted (gerade jetzt, keine vier Stunden), da die MultiplyInheritedClass ist der falsche Ort um das virtuelle Vererbung. Die virtuelle Vererbung eingesetzt werden, sowohl in der FirstConcreteClass und SecondConcreteClass. Die MultiplyInheritedClass verwenden sollten einfache öffentlicher Vererbung (es sei denn, es könnte auch verwendet werden, in einigen anderen meta-Diamant-Muster).
    • Guter Punkt, danke - werde ich ändern!
    • Downvote eingefahren. Vielen Dank für das update, Kerrek.
    • Eine neue und andere Meinung ist unten jetzt 🙂
    • OK, ich habe es: das, Was ich meinte ist, dass konnte ich "beheben" meine erste, nicht-virtuellen Beispiel, indem Sie explizit die Kommissionierung eine Basis über A * px = static_cast<B1*>(new C);, und dann px->foo() würde Folgen Sie den entsprechenden Pfad (nämlich A zu B1 zu C).
    • Yep, aber brauchen noch nicht einmal den cast, da Sie convertring zu (einer) der Basisklasse.
    • In der nicht-virtuellen gibt es z.B. beiden Basis Unterobjekte vom Typ A, so dass die gerade gegossen ist zweideutig - deshalb der Mittelstufe werfen.
    • Jetzt war meine Zeit, um es falsch 😉 (ich war auf der Suche auf Ihre Diamant-Diagramm), die Ursache-du hast Recht. Interessanterweise ist dies der Fall, wenn static_cast wird verwendet, um eine operation durchführen, die sonst nicht (waren es nicht für den interm. Schritt) benötigt werden.
    • "error, ambiguous override" warum?

    InformationsquelleAutor Kerrek SB
  2. 5

    Deinem ersten Beispiel nicht, weil der compiler kann keine Verwechslungen zwischen den drei Implementierungen von implementation(). Sie überschreiben diese Methode in MultiplyInheritedClass, die eigentlich überschreibt sowohl FirstConcreteClass::implementation und SecondConcreteClass::implementation (einmal virtuell, immer virtuell). Aber beide virtuellen fordert, noch existiert in der Schnittstelle MultiplyInheritedClass, wodurch der Aufruf mehrdeutig an der call-site.

    Den Grund, dass dein Beispiel funktioniert, ohne virtual Vererbung ist, dass es keine widersprüchlichen Umsetzung der gemeinsamen Basisklasse. Anders ausgedrückt:

    class Base
{
public:
    void DoSomething() {
    std::cout << "TADA!";
    }
}

class One : public Base
{
    //...
}

class Two : public Base
{
    //...
}

class Mixed : public One, public Two
{
    //...
}

int main()
{
    Mixed abc;
    abc.DoSomething(); //Fails because the compiler doesn't know whether to call
                       //One::DoSomething or Two::DoSomething, because they both
                       //have implementations.

    //In response to comment:
    abc.One::DoSomething(); //Succeeds! You removed the ambiguity.
}

    Weil dein Beispiel hat rein virtuelle Funktionen, es gibt keine multiple-Implementierungen, die der compiler braucht, um keine Verwechslungen. Daher nur eine Implementierung vorhanden ist, und der Aufruf ist eindeutig.

    • Ich habe die zweite code-segment oben, so dass die taggingInterface ist jetzt überschreiben von jeder Schnittstelle (obwohl der Unterschied kann sein, dass es keinen Umweg über eine private member-Funktion wie in dem ersten Beispiel?). Wirkt sich das auf/ändern Sie Ihre Antwort an alle?
    • 1. Dass code nicht kompilieren. (Es gibt fehlerhafte = Zeichen, die nicht dort sein sollte.) 2. Was bedeutet der call-site Aussehen? Dein erstes Beispiel hat ein call-site, das zweite Beispiel nicht.
    • Es nicht scheitern, es funktioniert gut auf VC++ 2008 wenn Sie den code duplizieren von DoSomething, anstatt jeden Kommentar.
    • 1. Wen interessiert das, was VC++ tut? Die meisten von uns, egal, was der standard sagt, es hat zu tun, denn wenn man auf mehr als einen compiler werden Sie unterschiedliche Ergebnisse erhalten, wenn Sie verlassen sich auf etwas flippig. (VC++ bekannt werden, zu verzeihen, Dinge wie diese) 2. Wenn Sie duplizieren, dass code, der in jedem Kommentar, dann werden Sie völlig verändern den Zusammenhang von meinem Beispiel. Dann ist die Funktion in Mixed einfach versteckt One::DoSomething und Two::DoSomething so dass es keine Zweideutigkeit. Der Kommentar bedeutet "Wirklich spielt keine Rolle, was Sie hier" so lange, wie Sie nicht umsetzen DoSomething().
    • ONeal Sie die Bemerkung war auf die Notiz über den Anruf Seite: ich wusste gar nicht, dass der code kompilieren fein zur Verfügung gestellt eine mehrdeutige Anruf nie gemacht. Ich dachte, es wäre ein vorbeugender Warnung/Fehler für das design, unabhängig davon, wie es tatsächlich verwendet wurde.
    • Nein-es ist völlig legal für jemanden zu gehen (aus meinem zweiten Beispiel) abc.One::DoSomething() (wo abc ist einer von denen, gemischte Objekte) -- das wäre nicht sein Fehler, aber es ist ein Diamant-Muster (die Sie gerade entfernt die Mehrdeutigkeit).
    • Bearbeitet das zweite Beispiel oben zu zeigen.
    • wenn dies zu überschreiben, sollte nicht die Methoden virtuell sein? wenn dem so ist, warum reden wir über die "drei Implementierungen von implementation" (das ist nicht virtuell in OP ' s Beispiel)? etwas scheint hier falsch..
    • Nein. Die einfache Vererbung ist ausreichend, um zu veranschaulichen den Punkt. Die Methode der virtuellen ändert sich nichts. Noch, das Problem ist der doppelte Implementierungen aufgrund der Basis-Klasse zweimal dabei.
    • siehe ideone.com/nXbNb, alles scheint in Ordnung (gibt es, für den g++ 4.3, zumindest); neben Cameau c++ (comeaucomputing.com/tryitout) und llvm (llvm.org/demo/index.cgi) sowohl das kompilieren der gleiche code erfolgreich.
    • Das ist nicht mein Beispiel. Nun in beiden Fällen versteckte sich die Basis-Methode der Klasse, die wird die Mehrdeutigkeit aufgelöst. Sie haben zu entfernen, die Implementierungen in ein -, zwei -, und gemischte, oder die Basis eines virtuellen, um zu sehen, dieser Effekt. Sie werden sehen, dass, wenn Sie kompilieren meinem eigentlichen Beispiel schlägt fehl: ideone.com/RmJQU
    • Die OP ' s original-Beispiel kompiliert, weil er nie aufgerufen wird, eine der Methoden. Der Fehler tritt bei der call-Seite.
    • ok, aber bitte siehe ideone.com/8pnN2 für die OP ' s erste Beispiel (das auch erfolgreich kompiliert unter Cameau und llvm) -- es nicht scheitern, bis etwas wie PureAbstractBase *pab = &mic; versucht wird (also das ist die mehrdeutige Konvertierung), d.h. der OP könnte die Methoden aufrufen, aber konnte nicht korrekt konvertiert werden
    • Ich habe meine Gedanken in eine Antwort, überprüfen Sie es unten 🙂

    InformationsquelleAutor Billy ONeal
  3. 1

    Ich habe versucht, sowohl die Frage der codes und Sie funktionierte wunderbar, wenn das instanzieren eines Objekts der multi-Klasse geerbt. Es hat nicht funktioniert, nur mit Polymorphismus, wie diese zum Beispiel:

    PureAbstractBase* F;
F = new MultiplyInheritedClass();

    Und der Grund ist klar: Sie weiß es nicht, auf die Kopie von der Abstrakten Basis-Klasse verknüpft werden sollten (sorry für die schlecht Ausdrücke, ich verstehe die Idee aber nicht, es auszudrücken). Und da inherting virtaully macht nur eine Kopie vorhanden ist, in der abgeleiteten Klasse, dann ist es gut.

    Auch den code von Billy ONeal überhaupt nicht klar, was sollten wir statt dessen von den Kommentaren?

    Wenn wir Platz:

    public:    
void DoSomething() 
{    std::cout << "TADA!";    }

    funktioniert es einwandfrei, weil keine Virtualität.

    Arbeite ich auf Visual Studio 2008.

    • Tamer: Man könnte etwas an der Stelle der Kommentare. (Ausgenommen eine Implementierung der rein virtuellen Funktion DoSomething), Wenn Sie ein problem haben mit meiner Antwort, Kommentar auf meine Antwort. Nicht nur posten, etwas anderes zu kritisieren mich und hoffe, dass ich es gelesen habe.
    • ONeal: sorry... du hast Recht 🙂
    InformationsquelleAutor Tamer Shlash
  4. 0

    Warum nicht tun Sie es wie diese (vorgeschlagen in Benjamin Supnik blog-Eintrag):

    #include <iostream>

class PureAbstractBase {
public:
    virtual void interface() = 0;
};

class FirstConcreteClass : public PureAbstractBase {
public:
    virtual void interface() { implementation(); }
private:
    void implementation() { std::cout << "Fisrt" << std::endl; }
};

class SecondConcreteClass : public PureAbstractBase {
public:
    virtual void interface() { implementation(); }
private:
    void implementation() { std::cout << "Second" << std::endl; }
};

class MultiplyInheritedClass : public FirstConcreteClass,
                               public SecondConcreteClass 
{
public:
    virtual void interface() { implementation(); }
private:
    void implementation() { std::cout << "Multiple" << std::endl; }
};

int main() {
MultiplyInheritedClass mic;
mic.interface();

FirstConcreteClass *fc = &mic; //disambiguate to FirstConcreteClass 
PureAbstractBase *pab1 = fc;
pab1->interface();

SecondConcreteClass *sc = &mic; //disambiguate to SecondConcreteClass 
PureAbstractBase *pab2 = sc;
pab2->interface();
}

    gibt:

    Multiple
Multiple
Multiple

    Diese Weise:

    • keine virtuellen Basen beteiligt sind (tun Sie Sie wirklich brauchen?)
    • können Sie rufen Sie die überschreiben-Funktion über einen eine Instanz der MultiplyInheritedClass
    • Mehrdeutigkeit wird beseitigt, indem ein zwei-Stufen-Konvertierung
    • Und die Antwort ist natürlich "nicht", dann 😉
    • Denn manchmal werden Sie wollen, stellen Implementierungen in der Basisklasse. Dieses Beispiel funktioniert iff gibt es keine Umsetzung auf der Spitze des Diamanten -- setzen Sie eine Implementierung dort ist der ganze Grund, warum virtuelle Vererbung besteht in den ersten Platz.
    • ONeal Naja, diese (OP ' s erste) genauen Fall nicht, die 'manchmal' (mein Beispiel genau folgt sein ein) 😉 Wieder setzen-Implementierung in der Basisklasse wäre trivial. Außerdem müssen wir möglicherweise Zustimmen, dass die Inbetriebnahme eine gemeinsamen Implementierung es ist, warum virtuelle Vererbung vorhanden ist, richtig?!
    InformationsquelleAutor mlvljr
Schreibe einen Kommentar