Inherited im Destroy notwendig?

[daywalker9]

Im Büro kam gerade die Diskussion auf: Ist ein Inherited im Destroy notwendig, wenn eine Klasse nur von TObject abgeleitet ist? Der eine sagt ja, der andere von nicht. Was ist den nun korrekt?

Beispiel:

Delphi-Quellcode:

type
  TTestClass = class
  private
    fVar : TList;
  public
    constructor create; 
    destructor destroy;override; 
  end;

constructor TTestClass.create;
begin
  inherited;
  fVar:=TList.create;
end;

destructor TTestClass.Destroy;
begin
  fVar.Free;
end;

[mkinzler]

Da TObject compiler magic verwendet, geht es m.W. auch ohne. Aber um mögliche Fehler wegen Änderungen in der Zukunft zu vermeiden, sollte man es trotzdem aufrufen.

[daywalker9]

Zitat von mkinzler:

... Aber um mögliche Fehler wegen Änderungen in der Zukunft zu vermeiden, sollte man es trotzdem aufrufen.

Ja, da waren wir uns auch einig.

[DeddyH]

In der System.pas von Delphi 2007 steht Folgendes:

Zitat:

Delphi-Quellcode:

destructor TObject.Destroy;
begin
end;

Ob man nun also inherited aufruft oder Peng. Aber mal anders herum gefragt: will man sich immer Gedanken machen, wovon die aktuelle Klasse jetzt abgeleitet wurde? Oder denkt man immer daran, falls man im Zuge der Entwicklung doch einmal auf eine andere Elternklasse ausweicht, den Destruktor anzupassen? Ich persönlich habe mir angewöhnt, immer explizit inherited aufzurufen, sowohl im Konstruktor wie auch im Destruktor, dann bin ich auf der sicheren Seite.

[himitsu]

Wenn man von TObject erbt, was der Standard ist, wenn man nix angibt, dann könnte man im Constructor und Destructor das Inherited weglassen.

Das Objekt selber wird quasi im BEGIN des Constuctor und END des Destructor erstellt/freigegeben.

Inherited sollte man aber dennoch immer angeben ... Nicht daß man es mal vergißt, sollte man einen vorhandenen Constuctor/Destructor überschreiben.
Lieber einmal zuviel, als einmal zu wenig und Schaden kann es eigentlich nicht.

Ich stimme da also vollkommen zu und "ja, man sollte es immer hinschreiben".
und wenn es an einer Stelle mal wirklich nicht der überschriebene Constructor/Destructor aufgerufen werden, dann besser einen Hinweis hinschreiben, warum das so ist.


Ich fände eine partiell deativierbare (ala reintroduce) Compilerwarung ganz nett, welche einen warnt, wenn kein Inherited vorhanden ist.