C++ "deadly diamond of death"

[Rasputin (Gast)]

Hallo,

ich habe ein Diamantenproblem. Leider konnte ich im Netz keine Lösung 
finden. (aber zumindest hab ich herausgefunden, wie sich das Problem 
nennt. ;) )

Ich möchte folgende Klassen:

Vereinfacht aus "diamond_a.cpp"

class istream {
protected:
   application *app;
}
class ostream {
protected:
   application *app;
}
class test : public istream, public ostream {
// auch in dieser Klasse wird app benötigt
}

hierbei gilt: innerhalb der Vererbung zeigt istream::app, ostream::app, 
test::app immer auf das selbe Objekt (muss!)! Nur der Compiler wird das 
vermutlich nicht verstehen. Darum dachte ich, ich mache eine Basisklasse 
für istream und ostream:

Vereinfacht aus "diamond_b.cpp"

class iostream {
protected:
   application *app;
};
class istream : virtual public iostream {
// in dieser Klasse wird app benötigt

};
class ostream : virtual public iostream {
// in dieser Klasse wird app benötigt

};
class test : public istream, public ostream {
// in dieser Klasse wird app benötigt
};

nur wie baue ich jetzt die constructors für die jeweiligen Klassen, dass 
alles korrekt initialisiert wird?

Ich hoffe, ich konnte mein Problem verständlich schildern.

Vielen Dank

[Dr. Sommer (Gast)]

Wie wäre es mit
virtual application* getApp () = 0; in beiden Basis Klassen? Und dann 
ohne Diamant.

[nicht"Gast" (Gast)]

Moin,


so ganz habe ich nicht verstanden, warum du App unbedingt in den 
Streamklassen brauchst, Das gehört eigentlich nicht dahin. Vielleicht 
ist auch der Name Application irreführend. Klingt, als wäre das die 
übergeordnete Anwendung.


Nur für die Puffergröße ist das aber auch albern. Dann sollte die App 
die Streams als Member haben und von dort stellst du dann den Puffer 
ein.

[Rasputin (Gast)]

Danke für eure Antworten.

@Dr. Sommer: ich denke mal darüber nach.

nicht"Gast" schrieb:
> Vielleicht
> ist auch der Name Application irreführend.

Gut möglich, ich tu mich mit dem benennen von Klassen und Funktionen 
immer schwer. :(
in der applikation-klasse wird u.A. auch die sample rate gespeichert, 
und geplant sind auch events (z.B. onSampleRateChange) wo sich die 
Objekte registrieren können, um dann entsprechend reagieren zu können 
(Koeffizienten neu berechnen, Puffer vergrössern). Also im Prinzip soll 
alles da rein, was potentiell die ganze Anwendung betrifft, aber nicht 
statisch ist. Vielleicht wäre setting ein passenderer Name.

[tictactoe (Gast)]

Rasputin schrieb:
> nur wie baue ich jetzt die constructors für die jeweiligen Klassen, dass
> alles korrekt initialisiert wird?

Etwa so:

class iostream {
protected:
   application *app;
public:
   iostream(application *app) : app(app) {}
};
class istream : virtual public iostream {
// in dieser Klasse wird app benötigt
public:
   istream(application *app) : iostream(app) {}
};
class ostream : virtual public iostream {
// in dieser Klasse wird app benötigt
public:
   ostream(application *app) : iostream(app) {}
};
class test : public istream, public ostream {
// in dieser Klasse wird app benötigt
public:
   test(application *app) : iostream(app) {}
   // muss evtl auch so aussehen, hab es nicht getestet:
   // test(application *app) :  istream(app), ostream(app), iostream(app) {}
};

Insbesonders ist es notwendig, die indirekte Basisklasse iostream vom 
test-Konstruktor aus aufzurufen, weil es eine virtuelle Basisklasse ist 
und test die oberste Klasse in der Hierarchie (sog. "most-derived 
class").

[Rasputin (Gast)]

Habe gerade gemerkt, dass das Problem - wie so oft - gar nicht dort 
steckt, wo ich dachte. Es hat allerdings immer noch mit dem 
diamond-problem zu tun, und zwar dann wenn man diesen weiter vererbt.

das funktioniert:

class test : public istream, public ostream {
public:
  test(audio::application *app_) : istream(app_), ostream(app_), iostream(app_) {
  }

  void process() {
    printf("%i", out);
  }
};

folgendes nicht:

class interface : public istream, public ostream {
public:
  interface(audio::application *app_) : istream(app_), ostream(app_), iostream(app_) {
  }
};

class test : public interface {
public:
  test(audio::application *app_) : interface(app_) {
  }

  void process() {
    printf("%i", out);
  }
};

Fehler:

main.cpp: In constructor 'audio::test::test(audio::application*)':
main.cpp:83:50: error: no matching function for call to 'audio::iostream::iostream()'
   test(audio::application *app_) : interface(app_) {
                                                  ^

Im Anhang ist ein kompilierbarer Code.
Mit #define SHOWERROR 1 bzw. 0 könnt ihr zwischen Funktionierend und 
Nicht-funktionierend hin und her schalten.

[tictactoe (Gast)]

Wie gesagt, wenn man eine virtuelle Basisklasse hat, dann kann man deren 
Initialisierung nicht delegieren, jede "most-derived class" muss es 
immer wieder selbst machen:

class test : public interface {
public:
  test(audio::application *app_) : interface(app_),  iostream(app_) {
  }
  //...
};

[Rasputin (Gast)]

Danke dir, tictactoe! Funktioniert!

Aber um ehrlich zu sein, verstehe ich die Logik dahinter nicht.
Dass "interface" "iostream" explizit initialisieren muss, kann ich noch 
verstehen. Aber wenn "test" "interface" und "iostream" initialisiert, 
wird "iostream" doch dann zwei mal initialisiert (einmal direkt und 
einmal über "interface")... hmmm...

[Rolf M. (rmagnus)]

Nein, weil bei virtueller Vererbung immer die am weitesten abgeleitete 
Klasse die virtuelle Basis inizialisiert. Wenn du also ein test 
erzeugst, initialisiert das darin enthaltene interface dann nicht den 
iostream.