[Tutorial] Den Destruktor verstehen

[himitsu]

Zitat von sx2008:

Beim Destruktor ist das verboten! Die Kette der Destruktoren muss abgearbeitet werden; sie darf nicht unterbrochen werden. Falls doch, droht ein Resourcen-/Speicherleck.

Doch, ist es ... wenn ich den Constructor ebenfalls übergangen hab und/oder für die Freigaben selbst gesorgt hab.
(praktisch für einen Bugfix)

Zitat:

Resourcen (Speicher, Handles,...) sollten immer in umgekehrter Weise freigegeben werden, in der sie angefordert wurden; das ist der sicherste Weg.

Wenn das schon anders erstellt wurde, dann stimmt es auch wieder.

[sx2008]

Zitat von himitsu:

Zitat von sx2008:

Die Kette der Destruktoren muss abgearbeitet werden; sie darf nicht unterbrochen werden. Falls doch, droht ein Resourcen-/Speicherleck.

Doch, ist es ... wenn ich den Constructor ebenfalls übergangen hab und/oder für die Freigaben selbst gesorgt hab.

Nein, ein Destruktor einer Klasse hat eine ganz bestimmte Verantwortung:
1.) er muss die lokalen belegten Resourcen seiner Klasse freigeben!

2.) er muss die Resourcen freigeben, die seiner Klasse überantwortet wurden
Zum Beispiel übernimmt die Klasse TComponent die Verantwortung dafür, dass alle Objekte im Components[]-Array im Destruktor entsorgt werden.

3.) er muss seiner Vaterklasse die Möglichkeit geben sich selbst aufzuräumen in dem er inherited aufruft.
Was im Destruktor der Vaterklasse passiert und ob dessen Konstruktor aufgerufen wurde oder nicht hat nicht zu interessieren.
Der Sourcecode der Vaterklasse muss als Blackbox betrachtet werden;
es muss völlig egal sein was in der Vaterklasse an Resourcen belegt wurde oder nicht.
Wichtig ist allein nur der Vaterklasse über den Aufruf von inherited die Chance zu geben, alle belegten Resourcen zu entsorgen.

4.) er muss so programmiert sein, dass selbst wenn ein Objekt nur teilweise initialisiert wurde (z.B. Exception im Konstructor) er gefahrlos die bislang belegten Resourcen freigibt.

Das sind die Regeln; das ist der (ungeschriebene) Vertrag der bei Ableitung einer Klasse geschlossen wurde.

[Blup]

In 99,9% aller Fälle sind deine Regeln zutreffend, es kann Ausnahmefällen geben, allerdings sollte eine Regel immer eingehalten werden: Der Destructor "Destroy" muss immer in der Lage sein das Objekt korrekt freizugeben.

Ein kleines Beispiel mit Zirkelbezug:

Delphi-Quellcode:

TPartnerObject = class(TObject)
protected
  FPartner: TPartnerObject;
public
  // darf nicht mehr überschrieben werden
  destructor Destroy; override; finally;
  // kann in abgeleiteten Klassen überschrieben werden
  destructor MyDestroy(Sender: TObject); virtual;
  property Partner: TPartnerObject read FPartner write FPartner;
end;

// bleibt weiterhin voll funktionsfähig
destructor TPartnerObject.Destroy;
begin
  MyDestroy(Self);
end;  

// Destroy ruft immer das für die Klasse gültige MyDestroy auf
destructor TPartnerObject.MyDestroy(Sender: TObject);
begin
  if Assigned(FPartner) and (FPartner <> Sender) then
    FPartner.MyDestroy(Sender);

  inherited Destroy;
end;


Kette := TPartnerObject.Create;
Kette.Partner := TPartnerObject.Create;
Kette.Partner.Partner := TPartnerObject.Create;
Kette.Partner.Partner.Partner := Kette;

FreeAndNil(Kette);

[BUG]

Delphi-Quellcode:

Kreis := TPartnerObject.Create;
Kreis.Partner := TPartnerObject.Create;
Kreis.Partner.Partner := Kreis;
Stiel := TPartnerObject.Create;
Stiel.Partner = Kreis;
Stiel.free(); // Stackoverflow? (Ungetestet: hab grad kein Delphi zur Hand)

Wuhaha, Kreis am Stiel

Eine Variante, die auch dieses Problem lösen sollte:

Delphi-Quellcode:

TPartnerObject = class(TObject)
private
  FDieing: boolean;
protected
  FPartner: TPartnerObject;
public
  constructor Create;
  destructor Destroy; override;
  property Partner: TPartnerObject read FPartner write FPartner;
end;

constructor TPartnerObject.create;
begin
  FDieing := false;
  FPartner := nil;
end;

destructor TPartnerObject.Destroy;
begin
  FDieing := true;
  if assigned(Partner) then
    if not FPartner.Dieing then
      FPartner.Destroy; // ist schon auf nil überprüft
  inherited;
end;

Das würde bei auch mehreren Partnern funktionieren und entspricht der Tiefensuche in einem Graphen.

[Blup]

Natürlich gibt es für ein Problem immer mehrere Lösungen und in diesem konkreten Fall würde ich die Variante mit dem Flag vorziehen. Aber das ist nur ein Beispiel, das den richtigen Einsatz eines zweiten Destruktors demonstrieren soll.