destructor, destroy und free

[Minz]

Hallo nochmal,

es war doch so wenn ich Free aufrufe,
das erst geprüft wird, ob das Objekt
überhaupt existiert und erst dann
destroy ausgeführt wird?

Wenn ich ein Objekt lösche, an dem noch
weitere Objekte dranhängen, muss ich den
destructor erweitern.

Kann/Muss ich da

destructor Free(variablen); oder
destructor Destroy(variablen);

benutzen?

Ich will halt nur sicher gehen, dass die
Objekte beim Programmabbruch auch wirklich
gelöscht werden, und das lässt sich schlecht
überprüfen, oder?

[Christian Seehase]

Moin Minz,

Du musst nur Objekte mit Free freigeben, wenn Du ihnen keinen Owner zugewiesen, also sie mit Create(nil) erzeugt hast.
Hast Du einen Owner zugewiesen, werden sie automatisch zerstört, also freigegeben, wenn der Owner zerstört wird.

War's dass, was Du wissen wolltest? So ganz verstanden hab' ich Deine Frage nämlich nicht. ;-)

[Minz]

Geht schon in die Richtung.

Also:
MeinObjekt1
Constructor...
Destructor Free/Destroy...

MeinObjekt2

Eine Instanz von MeinObjekt1 wird gelöscht.
Diese Instanz verwendet Instanzen von MeinObjekt2
Owner werden nicht angegeben.
Gelöscht werden die Instanzen mit Free.
Muss ich bei dem Destructor die Methode
Free oder Destroy verwenden?
In dem Destructor sollen dann Instanzen von
MeinObjekt2 gelöscht werden.

Ich kanns irgendwie nicht anders ausdrücken :oops:

[fiasko]

Zitat:

Zitat von Minz

Muss ich bei dem Destructor die Methode
Free oder Destroy verwenden?

Einfach mal debuggen ;-) - kann mich nur erinnern, da bei meinen Threads, wo ich immer Destroy überschreibe, dieser Destructor auch aufgerufen wird, auch wenn ich MyThread.Free bzw. MyThread.FreeOnTermination:=True verwende.


Thomas

BTW: Kann mal einer sagen, wie Free prüft, ob das Objekt existiert? Was meinte die Borland Hilfe da? Wenn MeinObject auf nil zeigt, dann fliegt der doch sowieso raus, wenn ich MeinObject.Free aufrufe?!

[Christian Seehase]

Moin Minz,

ich hoffe mal es jetzt verstanden zu haben ;-)

Bei der Deklaration einer Klasse als Destructor (soweit erforderlich, was ja in Deinem Falle sein muss) immer Destroy nehmen.

Delphi-Quellcode:

public
  destructor Destroy; override;

In der eigentlichen Routine wird dann für die jeweils enthaltenen freizugebenden Objekte (die wohl meist im Create erzeugt wurden), jeweils deren Free Methode aufgerufen (oder die Prozedure FreeAndNil verwendet)

Als Letztes muss jetzt noch, der geerbte destructor aufgerufen werden.

Delphi-Quellcode:

destructor MeinObjekt.Destroy;
begin
  // Was es alles so freizugeben gibt
  inherited Destroy;
end;

War ich jetzt dicht dran?

@Thomas
Wie Free das prüft kann ich Dir sagen:
Wenn Du IrgendEinObjekt.Free in den Code schreibst, generiert der Compiler einen Aufruf für TObject.Free.
Dort wird geprüft, ob denn überhaupt ein Objekt da ist (<> nil), von wo der Aufruf erfolgte, und beendet dann die Prozedur Free, wenn kein Objekt vorhanden war.
Ansonsten wird in die zum Objekttyp gehörige Destroy Routine verzweigt.
Würdest Du direkt Destroy aufrufen, wird diese Prüfung übersprungen, und das Programm läuft, bei nicht vorhandenem Objekt, über kurz oder lang auf einen Fehler.

[fiasko]

OK, ich lese gerade das es wohl auch Klassenmethoden in Delphi gibt - damit ist alles klar (bis auf das mit dem FreeAndNil, aber da schaue ich doch erstmal in die Hilfe :-).


Thomas

[Motzi]

Zitat:

Zitat von fiasko

Kann mal einer sagen, wie Free prüft, ob das Objekt existiert? Was meinte die Borland Hilfe da? Wenn MeinObject auf nil zeigt, dann fliegt der doch sowieso raus, wenn ich MeinObject.Free aufrufe?!

Free macht im Prinzip nichts anderes, als zu überprüfen ob der Self-Pointer nil ist oder nicht und ruft dann bei Bedarf eben Destroy auf. Der Self-Pointer ist (soweit ich weiß) immer in eax. dh. wenn du eine Objekt Methode aufrufst über irgendeinObjekt.Methode, so wird zuerst der Pointer von irgendeinObjekt in eax kopiert und dann die Methode aufgerufen...

[Christian Seehase]

Moin Thomas,

Zitat:

ich lese gerade das es wohl auch Klassenmethoden in Delphi gibt

:wiejetzt:

:mrgreen:

[fiasko]

Zitat:

Zitat von Christian Seehase

:wiejetzt:

Das Frag ich mich langsam auch... die OOP Implementierung ist ja sowas von:

Delphi-Quellcode:

program Project1;
{$APPTYPE CONSOLE}
uses
  sysutils;

begin
  writeln(TObject.ClassName);       // 1.
  writeln(TObject(nil).ClassName);  // 2.
  TObject.Free;                     // 3.
  TObject(nil).Free;                // 4.

  readln;
end.

So, nun rate mal einer was sich kompilieren läßt, was eine AV wirft und was funzt:

Code:

 1: geht, da Klassenmethode,
 2: geht nicht (AV), weil keine Ahnung warum,
 3: geht nicht zu kompilieren, 
 4: geht weil Delphi's OOP einfach dumm implementiert ist, denn Free
   ist als stinknormal procedure Free; deklariert - das geht
   auch mit jeder anderen eigenen Methode, solange man nix vom Objekt
   selber will

Nach meiner Meinung, müßte 3. und 4. eigentlich immer rausfliegen, denn wie soll man denn eine Methode eines Objektes aufrufen, das garnicht existiert (vom logischen Ansatz her). Geht den so was in anderen Sprachen?!


Thomas

[Christian Seehase]

Moin Thomas,

Fall 1 funktioniert, weil eine Klasse immer einen Namen hat (Da kannst Du auch beliebige andere Klassen ausser TObject nehmen)

Fall 2 Geht schief, weil Du hier explizit den ClassName eines, vermeintlich, existierenden Objektes abfragst, was, auf Grund von nil, dann vor die Wand läuft.

Fall 3 lässt sich nicht kompilieren, weil Du kein Objekt sondern eine Klasse angegeben hast. Nur die Objekte können die Methoden ausführen.

Fall 4 hatte ich schon mal weiter oben beschrieben. Es spielt keine Rolle, ob Du nun eine Variable mit dem Typ einer von TObject abgeleiteten Klasse, und dem Wert nil angibst, oder TObject(nil) schreibst.