Warum virtuelle Destructoren?

[JasonDX]

Zitat von Hansa:

Ja, was soll denn überschrieben werden ? Da ist doch nichts vorher.

Ich weiss ja nicht, wie's bei dir aussieht, aber mein TObject hat sowas drinstehn:
destructor Destroy; virtual;

greetz
Mike

[Hansa]

Jason, ich meine das hier :

Delphi-Quellcode:

type 
  TFIFO = class 
        destructor Destroy; override; 
      end;

Delphi wird das schon schlucken. Nur, was soll das ?

[JasonDX]

Zitat von Hansa:

Nur, was soll das ?

So wies aussieht soll das den virtuellen Destruktor ueberschreiben.

greetz
Mike

[Hansa]

Dann zeige mal wo der sein soll. Mittlerweile auch gemerkt, dass da was nicht stimmt ? Oder, was habe ich in Object-Pascal wann verpasst ?

[Dax]

In TObject?

[JasonDX]

Zitat von Hansa:

Dann zeige mal wo der sein soll.

Spielen wir grad blinde Kuh?
Hier hab ichs schon mal geschrieben: TObject enthaelt einen virtuellen Destruktor:

Delphi-Quellcode:

Type
  TObject = Class
  Public
    destructor destroy;virtual;

greetz
Mike

[Hansa]

Blinde Kuh ? Ja wär doch gut.

Nächster Versuch :

Delphi-Quellcode:

type 
  TFIFO = class 
  private 
    Type 
      TNode = class 
      private 
        FNext: TNode; 
        FObject: TObject; 

      public 
        constructor Create(AObject: TObject); 
        destructor Destroy; override; 
      end;

Erkläre mir mal bitte, warum da ein Destructor einer leeren Class TFIFO (also ohne Vorfahr) per override überschrieben werden muss. Mehr will ich gar nicht wissen. Wer soll mit dem "override" denn überhaupt angesprochen werden ?

[JasonDX]

Zitat von Hansa:

Erkläre mir mal bitte, warum da ein Destructor einer leeren Class TFIFO (also ohne Vorfahr) per override überschrieben werden muss. Mehr will ich gar nicht wissen. Wer soll mit dem "override" denn überhaupt angesprochen werden ?

Wenn nicht anders angegeben, wird jede Klasse von TObject abgeleitet und erbt damit all ihre Methoden. Inklusive dem virtuellen Destruktor, der dann ueberschrieben wird.

gute Nacht
Mike

[Muetze1]

Ich hänge dazu nochmal schnell die Meinung der OH an, welches dies auch ausdrücklich beschreibt:

Zitat von oh:

Wenn Sie in der Deklaration eines Klassentyps keinen Vorfahren angegeben, erbt die Klasse direkt von TObject. Aus diesem Grund ist die Deklaration

Delphi-Quellcode:

TMyClass = class
 ...
end;

identisch mit

Delphi-Quellcode:

type TMyClass = class(TObject)
 ...
end;

Die zweite Variante verdient jedoch aus Gründen der Lesbarkeit den Vorzug.

@Hansa: Bei C++ bzw. speziell dem BCB wäre es wichtig bzw. ein Unterschied für die VCL Klassen bzw. C++ Klassen. Diese können auch nicht vermischt werden, aber in Delphi gibt es immer nur die VCL Klassen, und die erben grundsätzlich von TObject, wenn nicht explizit anders angegeben.

/EDIT: Wenn du das Override nicht angibst, dann erhälst du zum einen einen Hinweis/Warnung vom Compiler und zum anderen wird dein Destructor nie ausgeführt.

[IngoD7]

Zitat von Muetze1:

/EDIT: Wenn du das Override nicht angibst, dann erhälst du zum einen einen Hinweis/Warnung vom Compiler und zum anderen wird dein Destructor nie ausgeführt.

Das bedarf aber noch ein paar Erklärungen.

Er wird nur dann nicht ausgeführt, wenn zum Freigeben von TMeinObjekt ein MeinObjekt.Free benutzt wird. Free ist von TObject geerbt und ruft eben nur den Destruktor destroy von TObject auf, wenn dessen Virtualität nicht Rechnung getragen wird in den abgeleiteten Klassen. Durch ein override würde MeinObjekt.Free den Destructor destroy von TMeinObjekt aufrufen. Daher sollten Destruktoren in der Regel immer ihren Ahnen per override überschreiben. Eben weil sonst ein Free den eigenen Destruktor nicht "erreichen" würde, sondern in TObject "hängenbleiben" würde.

Nun kann man aber locker auch den Destruktor direkt aufrufen, um ein TMeinObjekt freizugeben: MeinObjekt.Destroy.
In diesem Fall würde der Destruktor von TMeinObjekt immer aufgerufen werden, ohne jegliche Relevanz dessen, ob er seinen Ahnen in TObject überschreibt oder nicht.
Allerdings ist diese Art des Destruktoren-Aufrufs nicht sooo sonderlich empfehlenswert, weil zuvor überprüft werden muss, ob MeinObjekt nicht schon nil ist. Nichts anderes macht nämlich TObject.Free.