valgrind ausgabe



  • Hat DeliverableObject einen virtuellen Destruktor? Sonst wird nämlich immer nur das Basisklassenteilobjekt aufgeräumt.



  • Hat DeliverableObject einen virtuellen Destruktor?

    DeliverableObject koennte auch ein BEvent-Zeiger als Member haben, ohne virtuellen Destruktor.



  • knivil schrieb:

    Hat DeliverableObject einen virtuellen Destruktor?

    DeliverableObject koennte auch ein BEvent-Zeiger als Member haben, ohne virtuellen Destruktor.

    Dann ist das gezeigte delete nicht das, welches das Event löscht.



  • manni66 schrieb:

    knivil schrieb:

    Hat DeliverableObject einen virtuellen Destruktor?

    DeliverableObject koennte auch ein BEvent-Zeiger als Member haben, ohne virtuellen Destruktor.

    Dann ist das gezeigte delete nicht das, welches das Event löscht.

    Whatever, der Destruktor kann aber das Event loeschen und dann waere gezeigtes delete dafuer verantwortlich. Es bringt jetzt nichts alle Moeglichkeiten durchzuraten. Es koennte auch ganz anders sein.



  • hallo zusammen,

    sorry, gestern abend war ich unterwegs und hab nicht mehr reingeschaut. freut mich, dass die frage soviel interesse weckt! 😉

    es scheint in der tat der fehlende virtuelle konstruktor gewesen zu sein. diesen hinzugefügt und valgrind ist glücklich. heißt das, wenn delete aufgerufen wurde, dass da nur das deliverableObject gelöscht wurde, und die darauf aufbauenden events blieben übrig?

    was sind nochmal die großen drei?

    ich danke euch vielmals. 😃





  • Bitte beantworte doch erstmal die Frage, wie beide Klassen in Beziehung stehen.

    da nur das deliverableObject gelöscht wurde, und die darauf aufbauenden events blieben übrig

    Das kommt drauf an, wie die Klassen zueinander in Beziehung stehen. Ansosnte: Ja, wenn BEventGroup<BEvent> von DeliverableObject erbt.

    Ansosnten: CRTP nutzen aber Grundlagen nicht verstehen. Irgendwas laeuft falsch.



  • ja, ein event ist ein deliverable object.

    crtp haben wir ja nicht genommen weil es so fancy ist, sondern weil es der einzige weg war, den wir gefunden hatten um das abonnieren von eventgruppen zu ermöglichen. lieber wäre es mir ohne gewesen. 😉



  • nachtrag:

    das man copy constructor, zuweisungs operator und destructor immer angeben soll weiß ich. mir war es bloß nicht unter dem begriff der großen drei geläufig und da der hinweis bezüglich des eventhandlers gemacht wurde auch gerade nicht klar.



  • sven_ schrieb:

    das man copy constructor, zuweisungs operator und destructor immer angeben soll weiß ich.

    Das ist aber falsch. Die Regel der Grossen Drei besagt nur, dass wenn du einen der drei implementierst, du dann meistens auch die anderen zwei brauchst. In C++11 ist es mit Move-Konstruktor und Move-Zuweisungsoperator die Regel der Grossen Fünf.

    Ich würde sogar behaupten, im Allgemeinen ist es gut, wenn man diese Memberfunktionen dem Compiler überlassen kann. Es zeigt nämlich, dass man gut von Low-Level-Operationen wie Speicherverwaltung, Kopieren, etc. abstrahiert hat und sich Objekte selbst kopieren/verschieben können. Gibt natürlich Fälle, wo eine Implementierung trotzdem nötig ist, meist wegen Exceptionsicherheit.

    Interessanter Artikel: Rule Of Zero


Anmelden zum Antworten