Interessantes Destruktor Problem

[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.

[Deep-Sea]

@SirThornberry:
Es war ja auch nur ein Beispiel, was mir im damaligen Thread spontan eingefallen ist. Über Sinn oder Unsinn einen Konstruktor derart zu überschreiben ging es bei der Diskussion aber auch nie

PS: Der "alte" Konstruktor, der den Stream erwartet, könnte z.B. (strict) protected sein, so kann man ihn nicht so aufrufen, wie in deinem Beispiel ...

[SirThornberry]

Achso. Auf jeden Fall ist an dem diskutierten nichts verwerfliches. Wie bereits beschrieben wird der Speicher schließlich vorm Constructor-Aufruf reserviert und nach dem Destructor-Aufruf freigegeben. Und auch in anderen Programmiersprachen ist das nicht viel anders.