Nicht virtueller Destruktor -> undefiniertes Verhalten?
-
Ich hätte gesagt es führt zu
C::C()
B::B()
A::A()
A::~A()Destruktor ist im Grunde ja auch nur ne normale Methode, nur dass sie implizit aufgerufen wird, oder nicht?
Gruß
-
FireFlow schrieb:
Ich hätte gesagt es führt zu
C::C()
B::B()
A::A()
A::~A()Destruktor ist im Grunde ja auch nur ne normale Methode, nur dass sie implizit aufgerufen wird, oder nicht?
Gruß
nein, und zwar ganz einfach deshalb, weil der standard sagt, dass es so ist (UB). über das verhalten bestimmter implementationen brauchen wir da gar nicht diskutieren.
-
Wo steht das? O.o
Habs bei Special Methods -> Destructor und bei Derived Classes -> Virtual funtions nicht gefunden. Oder ist es gerade undefiniert weils nicht da steht?
Gruß
-
FireFlow schrieb:
Ich hätte gesagt es führt zu
C::C()
B::B()
A::A()
A::~A()Soweit sicher denkbar, aber was ist mit der Deallokation nach A::~A()?
-
FireFlow schrieb:
Wo steht das? O.o
Habs bei Special Methods -> Destructor und bei Derived Classes -> Virtual funtions nicht gefunden. Oder ist es gerade undefiniert weils nicht da steht?
Gruß
5.3.5/3
-
Bashar schrieb:
FireFlow schrieb:
Ich hätte gesagt es führt zu
C::C()
B::B()
A::A()
A::~A()Soweit sicher denkbar, aber was ist mit der Deallokation nach A::~A()?
A::~A() ruft den virtuellen Dtor von B::~B() auf, der kann aber C::~C() nicht aufrufen, da der nicht virtual ist? Also Objekt nicht vollständig abgebaut und somit undefiniertes Verhalten?
-
Bei gängigen Desktopimplementationen sollte es klar sein was hier passiert allerdings stell dir mal vor, dass du nicht eine so schöne Speicherverwaltung hast wo du nur einen Zeiger angeben musst um Speicher frei zu geben sondern auch noch die größe des Speicherblocks. Bei einen statischen Type kann der Compiler diesen Wert leicht herleiten, sollte es sich um einen dynamischen Type handeln schmuggelt der Compiler neben dem virtuellen Dtor noch eine weitere virtuelle Funktion rein mit dessen Hilfe er diesen Wert herleiten kann. Dies würde in deinem Beispiel aber nicht funktionieren und da der Standard ja dahingehen geschrieben wurde möglichst implementationsunabhängig zu sein könnte ich mir dies als Grund durchaus vorstellen das Verhalten hier undefiniert zu lassen. Ist aber nur meine Meinung.
:xmas1:
-
Ist was anderes... Hier gehts ja nur um den Destruktor, denn für 'normale' Methoden ist das Verhalten durchaus definiert.
Die eigentliche Frage ist ja schon geklärt.
Gruß
-
GPC schrieb:
A::~A() ruft den virtuellen Dtor von B::~B() auf, der kann aber C::~C() nicht aufrufen, da der nicht virtual ist? Also Objekt nicht vollständig abgebaut und somit undefiniertes Verhalten?
Sicher? Seit wann ruft der Destruktor denn Methoden von abgeleiteten Klassen auf? A weiß doch überhaupt nicht, daß B exisitiert.
(und außerdem: ~A() ist statisch, ~B() und ~C() sind virtuell (ersterer durch die Deklaration, letzterer implizit durch Vererbung))
-
CStoll schrieb:
GPC schrieb:
A::~A() ruft den virtuellen Dtor von B::~B() auf, der kann aber C::~C() nicht aufrufen, da der nicht virtual ist? Also Objekt nicht vollständig abgebaut und somit undefiniertes Verhalten?
Sicher? Seit wann ruft der Destruktor denn Methoden von abgeleiteten Klassen auf? A weiß doch überhaupt nicht, daß B exisitiert.
*Brett vorm Kopf hab*, Konstruktorreihenfolge ist ja "Von oben nach unten" und Destruktorreihenfolge "Von unten nach oben"