Interessantes Destruktor Problem

[sx2008]

Dieser Thread ist ein Spin-Off von Delphi Kurzreferenz

Dort hat Deep Sea folgenden Code gepostet:

Delphi-Quellcode:

constructor TAbgeleiteteKlasse.Create;
begin
  FStream := TMemoryStream.Create;
  inherited Create(FStream);
end;

destructor TAbgeleiteteKlasse.Destroy;
begin
  inherited; // Könnte ja auf den übergebenen Stream noch zugreifen.
  FStream.Free;
end;

Auf den ersten Bick sieht der Code korrekt aus, aber er trägt eine Zeitbombe in sich.
Nach dem Aufruf von inherited im Destruktor in der gesamte Speicher des Objekts freigegeben.
Es ist daher verboten nach diesem Zeitpunkt auf FStream zuzugreifen.
Das MemoryStream-Objekt selbst ist zwar noch intakt, aber die Variable FStream ist nicht mehr gültig.

In den allermeisten Fällen geht ein Zugriff auf diesen freigegebenen Speicher glimpflich ab.
Wenn man allerdings einen Memory-Manager (FasttMM4) benützt und dieser den freigegebenen Speicher
mit bestimmten Gardbytes füllt, dann wird das Problem offensichtlich.
Oder wenn ein anderer Thread zufällig gerade den Speicher bekommt der soeben im Destruktor freigegeben wurde dann gibt das ganz bösartige Probleme.

Ich behaupte also man darf so wie oben nicht programmieren und lade jeden ein sich zu überlegen, wie man das Problem umgehen könnte.

[mleyen]

Ich glaub ich habe das Problem nicht ganz verstanden.
Imho ist es nichtmal OOP-konform, wenn ein Objekt nach seiner Selbstzerstörung noch etwas macht.

[Neutral General]

Naja es geht wahrscheinlich nur darum, dass im Destructor das inherited ganz am Schluss aufgerufen werden soll/muss und nicht wie sonst meistens am Anfang der Methode. Aber die Codevervollständigung von neueren Delphiversionen legt Destructoren direkt schon so an:

Delphi-Quellcode:

destructor TKlasse.Destroy;
begin

  inherited;
end;

Ist also schon in der Codevervollständigung ein kleiner Wink mit dem Zaunpfahl

[Bummi]

@sx2008

wie kommst Du darauf daß der Code korrekt aussähe..

[generic]

Vererbung ist für diese Problem wohl nicht die Lösung.
Ein Composit(-Pattern) wäre besser geeignet.

[himitsu]

Zitat:

Delphi-Quellcode:

inherited; // Könnte ja auf den übergebenen Stream noch zugreifen.
FStream.Free;

Wenn FStream in der TAbgeleiteteKlasse deklariert ist, wie/wieso sollten dann dessen Vorfahre darauf zugreifen? Der Vorfahre kennt FStream doch nicht.
Es ist eher andersrum, also daß TAbgeleiteteKlasse auf Eigenschaften des Vorfahren zugreift.
Und wenn FStream im Vorfahren deklariert ist, dann ist dieser für dessen Erzeugung und Freigabe verantwortlich, womit dieses nicht in den Nachfahren reingehören würde.

Also im Constructur und anderen erzeugenden Routinen Inherited grundsätzlich als Erstes und im Destructor, sowie anderen freigebenden Routinen als Letzes.
Und sonst je nach dem, wie Dinge aus dem Vorfahren gebraucht/erzeugt/freigegeben werden.

[mkinzler]

Auch wenn es in diesem Beispiel geht, da ja Stream ein übergebener Parameter ist, sollte man die Reihenfolge konsequent einhalten.
Denn somst könnte es bei späteren Änderungen im Code zu Missverständnissen führen.
Ich würde auch zudem keine "externen" Objekte in einem Konstruktor erzeugen.

[s.h.a.r.k]

Zitat von himitsu:

Zitat:

Delphi-Quellcode:

inherited; // Könnte ja auf den übergebenen Stream noch zugreifen.
FStream.Free;

Wenn FStream in der TAbgeleiteteKlasse deklariert ist, wie/wieso sollten dann dessen Vorfahre darauf zugreifen? Der Vorfahre kennt FStream doch nicht.
Es ist eher andersrum, also daß TAbgeleiteteKlasse auf Eigenschaften des Vorfahren zugreift.
Und wenn FStream im Vorfahren deklariert ist, dann ist dieser für dessen Erzeugung und Freigabe verantwortlich, womit dieses nicht in den Nachfahren reingehören würde.

Ich weiß echt nicht, warum es hier so viele Diskussionen um sowas geben kann. Genau das war es, an was ich gedacht hatte, als ich den Code und vor allem den Kommentar dazu gelesen hatte. Das widerspricht ganz dezent dem, was ich mir unter OOP vorstelle.

[Uwe Raabe]

Zitat von himitsu:

Zitat:

Delphi-Quellcode:

inherited; // Könnte ja auf den übergebenen Stream noch zugreifen.
FStream.Free;

Wenn FStream in der TAbgeleiteteKlasse deklariert ist, wie/wieso sollten dann dessen Vorfahre darauf zugreifen? Der Vorfahre kennt FStream doch nicht.

Wie ich an anderer Stelle schon ausgeführt habe: Es kann sein, daß im inherited des Vorfahren eine virtuelle Methode aufgerufen wird, die im Kontext des Nachfahren halt doch auf FStream zugreift. Das Beispiel von TList.Destroy, daß virtuell Clear aufruft kommt in meinen Programmen bestimmt einige Male vor. Würde ich dort das Äquivalent von FStream vor dem inherited schon freigeben, würde das bestenfalls nur Zugriffsverletzungen zur Folge haben.

[SirThornberry]

Also ganz in Ordnung finde ich den Code auch nicht allerdings wegen etwas anderem.

Delphi-Quellcode:

constructor TAbgeleiteteKlasse.Create;
begin
  FStream := TMemoryStream.Create;
  inherited Create(FStream);
end;

destructor TAbgeleiteteKlasse.Destroy;
begin
  [...]
  FStream.Free;
end;

Und zwar ist hier ersichtlich das der Constructor der Vorfahrenklasse einen Constructor hat dem ein Stream übergeben wird.
Auch wenn der Constructor der neuen Klasse diesen Parameter nicht mehr hat ist es trotzdem noch möglich den Constructor der Vorfahrenklasse aufzurufen und den Stream zu übergeben. In dem Fall ist es Fatal das im neuen Destructor einfach mein übergebener Stream frei gegeben wird.

Bsp.:

Delphi-Quellcode:

var
  mystream: TStream;
  tmp: TAbgeleiteteKlasse;
begin
  MyStream := TMemoryStream.Create();
  tmp := TAbgeleiteteKlasse.Create(myStream);
  [...]
  tmp.Free;
  //jetzt ist plötlizlich mystream freigegeben obwohl das bei der Vorfahrenklasse noch nicht der Fall war
  [...]

Also ein eindeutiger Designfehler. Das worüber hier die ganze Zeit diskutiert wird kann ich nicht nachvollziehen denn es ist tatsächlich ab und zu der Fall das man erst nach dem inherited im Destructor etwas freigeben kann. Das ist zum Beispiel der Fall wenn im Destructor der Klasse von der man ableitet noch OnChange-Ereignisse/Speichern-Methoden etc. aufgerufen werden die durch Vererbung Dinge aus dem Nachfahren verwenden.