Logik Problem Konstrukor Mehrfahrvererbung (CStoll du wirst heute gefordert ;) )



  • Konstellation:

    class A{
    
      A(..){...}
    
    }
    
    class B1 : public virtual A{
    
      B1(..) : A(..){...}
    }
    
    class B2 : public virtual A{
    
      B2(..) : A(..){...}
    }
    
    class Komb : public B1, public B2{
    
     Komb(..) : B1(..), B2(..) {...}
    }
    

    Wemn ich nun ein Objekt von komb erzeuge, werden ja die Konsturktoren von B1, und B2 aufgerufen, welche wiederum (eine davon) den Konstrukor von A aufrufen..
    was aber nicht geht.. ich muss damit auch der Kontruktor von A aufgerufen, ihn in die Initialsieungsliste des Kontruktor von Komb anfügen..

    Lieg es daran das der kombiler vll. nich weis ob e rden Konstruktro von A übe B1 oder B2 aufrufen soll? Was kann ich da tun?



  • Das liegt an der virtuellen Vererbung - Du hast für die beiden Teile B1 und B2 nur einen gemeinsamen A-Anteil, deshalb weiß der Compiler nicht, welcher Ctor sich um dessen Initialisierung kümmern soll. Und die Lösung laut ANSI-Standard ist ganz einfach: Die unterste Klasse der Hierarchie muß alle virtuellen Basisklassen initialisieren.



  • Also:

    Komb(..) : A(..), B1(..), B2(..) {...}
    

    anders ist nich möglich?

    Aber immerhin bisher funktioniert hervorragend:)



  • Ja, so muß das aussehen 😉

    (CStoll du wirst heute gefordert 😉 )

    Hast du denn kein Buch, wo du solche Fragen nachlesen kannst 😃



  • ne .. glaub socleh vererbung infioramtionen gibts in keiner meiner Bücher, bzw. so Detailiert:)

    Aber es klappt ja jetzt ganz gut..der sinn der sache ist, das ich eine Klasse mit gemeinsemen Daten habe, und über jeweilige Ableitungen werden funktionen zur Bearbeitung oder Darstellung der Daten bereitgestellt. So bleiben die klassen klein und rel. Übersichtlich.. später kann ich dann durch Mehrfahvererbung die Funktionalitäten erben die ich brauch:)

    Macht doch Sinn, und danke für deine Hilfe CStoll;) Werden sicher noch mehr Fragen kommen;)



  • Zur Info: Du kannst auch auf die virtuelle Vererbung von A verzichten, dann hat B1 und B2 jeweils ein eigenes A.



  • ja das könnte ich... aber das geht nich, das ich ja immer auf die gleichen daten zugriefen will.... das ist ja der clou der geile virtuelen vererbung;)



  • Hmm, vielleicht wäre es da ein guter Punkt, das komplette Design zu überdenken. Solche Mehrfachvererbungen (gerade wenn sie gehäuft auftreten) sehen nicht nur hässlich aus, sie SIND hässlich.



  • Ja du hast vermutlich Recht... hatte auch frühr Probleme damit Mehrfachvererbungen zu verstehen, vorallem wenn die Basisklassen nicht im emferntesten was mit einadner zu tun haben

    class Haus : public Heizung, public Dachfenster{
    
    };
    

    in dem fall hatte ja ne Heitzung mit Dachfenster nich wirklich viel zu tun, und wird trozdme kombiniert wiel es zu eim Haus gehört, was vll. etwas Verwirrung schaft.

    In meinem Fall ist es aber gar nich so Verwirrend, im gengeteil hat sogar etwas zusammenhalt. So hat der Anlasser als Funktion under Vergasser als Funktion schon mehr zusammenhalt zum Motor.

    class Motor : public Anlasser, public Vergasser{
    
    }
    

    Das ist meine Meinung ... hisnichtlich meinees Designs;) hehe

    Hoffe ihr Versteht meine Intention:)



  • Also, nach der "ist ein" Regel ist das gegebene Beispiel schlecht, oder lieg ich da falsch?



  • Ja, ich verstehe, daß du noch viel über Klassenbeziehungen lernen solltest 😉 (öffentliche) Vererbung stellt eine "ist-ein"-Beziehung zwischen den Klassen dar. Ist ein Haus ein Dachfenster? Ist ein Motor ein Anlasser? (wenn du auf eine dieser Fragen mit "ja" antworten würdest, solltest du dich mal untersuchen lassen ;))

    Du benötigst eine "hat-ein"-Beziehung - das Haus hat Heizung, Dachfenster etc. und der Motor besteht aus Anlasser, Vergaser etc. Und das stellst du besser dar, indem du die Einzelteile als Member anlegst:

    class Motor
    {
      Anlasser m_anl;
      Vergaser m_verg;
    ...
    };
    


  • Ja ich versteh habt mich noch nich verstanden... Ist ne Interperationsache, jeder sieht es Subjektiv;) Naja weis auch nich wie ich das erklärne solte .. meine denkweise hat mit der "ist-ein" nichts zu tun:) Solagnsam werd ich Unsicher;)



  • Bedeutet der Smilie jetzt, dass es ironisch gemeint war? (nur um sicher zu gehen)



  • So ich hab ein Beispiel, auf das sich meine Inention bezeiht;)

    class Antrieb{
    
    };
    
    class Verbrennungsmotor : public virtual Antrieb{
    
    };
    
    class Elektromotor : public virtual Antrieb{
    
    };
    
    class HypridAntrieb : public Verbrennungsmotor, public Elektromotor{
    
    };
    


  • Jup, ein Haus ist nun mal keine Kombination aus einer Heizung und einem Dachfenster. Es hat höchstens diese beiden Elemente/Member.
    Naja, und das mit dem Antrieb: Ein HybridMotor hat ja nicht _alle_ Eigenschaften eines Verbrennungs- und Elektromotors, oder ?

    Gruß
    Don06



  • doch hat er:) sonst wärs ja kein richtiger Hypridmotor:)



  • Shinja schrieb:

    Also, nach der "ist ein" Regel ist das gegebene Beispiel schlecht, oder lieg ich da falsch?

    Ja, aber das ist ja das schöne an C++: Es scheißt auf "ist-ein" und verwendet Mehrfachvererbung, um Klassen mit Tags zu versehen.



  • Konrad Rudolph schrieb:

    Shinja schrieb:

    Also, nach der "ist ein" Regel ist das gegebene Beispiel schlecht, oder lieg ich da falsch?

    Ja, aber das ist ja das schöne an C++: Es scheißt auf "ist-ein" und verwendet Mehrfachvererbung, um Klassen mit Tags zu versehen.

    In C++ gibt es kein Sprachmittel, um zwischen "Ist ein"- und "Traits"-vererbung zu unterscheiden. Das fängt erst so langsam mit dem nächsten standard an, mit dem zum ersten mal möglich ist anzugeben, was ein Typ kann. Dann muss man nicht mehr für irgendwelche Tags vererben, weil Tags dann unnötig werden(wie die der iteratoren zb). Was dann noch fehlt, ist ein vererbungstyp, der zwar Methoden public zur verfügung stellt, aber der die konvertierung in den basistyp nicht erlaubt. Dann wär auch der Fall abgedeckt, dass Traits zusätzliche Informationen brauchen, um ihre Aufgabe zu erfüllen, und deswegen eigene methoden in die Klasse integrieren.

    @Boris

    class HypridAntrieb : public Verbrennungsmotor, public Elektromotor{
    
    };
    

    sehr gewagt. Ein hybridantrieb hat sowohl einen Verbrennungsmotor als auch einen Elektromotor, aber _ist_ es nicht. Ein Verbrennungsmotor kann nicht mehr fahren, wenn der tank leer ist, ein hybridantrieb schon. Q.e.d.



  • otze schrieb:

    Konrad Rudolph schrieb:

    Shinja schrieb:

    Also, nach der "ist ein" Regel ist das gegebene Beispiel schlecht, oder lieg ich da falsch?

    Ja, aber das ist ja das schöne an C++: Es scheißt auf "ist-ein" und verwendet Mehrfachvererbung, um Klassen mit Tags zu versehen.

    In C++ gibt es kein Sprachmittel, um zwischen "Ist ein"- und "Traits"-vererbung zu unterscheiden. Das fängt erst so langsam mit dem nächsten standard an, mit dem zum ersten mal möglich ist anzugeben, was ein Typ kann.

    Hmm. Mal abgesehen davon, dass Tagging nicht wirklich dasselbe ist wie Traits, auch nicht, wenn man von ihnen erbt: Welches Sprachmittel meinst Du im nächsten Standard? Concepts? Wie soll das hierbei helfen?



  • @otze: Rein technisch gesehen schon, aber der eltrokmotor ist ja im prinziop ein hilfsmotor für beschleunigungen, und ein zusätzliche bremswirkung (baterieladen). Wenn der Tank leer ist, wird sich das auot nich mehr zu näcsht teankstelle schleppen können (auser sie ist nur 2 km entfernt). Vergleichbar mit einem Kondensator welche kurzfristige benötigete energiespitzen ausgleicht;)

    Aber trozdem, das Beispiel hybridtmotor und virtuelle Mehrfachvererbung ist gell;) hehe


Log in to reply