Frage zu TThread.Free

[iphi]

Hallo,

ich starte einen Thread wie folgt:

Delphi-Quellcode:

type
  TCapture = class(TThread)
...

var
  Capture: TCapture;
...

Capture := TCapture.Create(...)  //1.
...
Capture.Terminate;               //2.
...
Capture.Free;                    //3.

Jetzt der Sachverhalt soweit ich ihn verstehe (bitte um Korrektur, falls ich falsch liege).
-Die Variable Capture ist ja wohl ein Pointer. Vor 1. ist der auf nil gesetzt.
-Bei 1. wird eine TCapture Datenstruktur erzeugt und Capture zeigt dann darauf.
-Bei 2. wird der Thread gestoppt, aber die Datenstruktur lebt noch.

Jetzt meine Frage:
-Bei 3. wird nach meinem Verständnis die Datenstruktur wieder vernichtet, d.h. eigentlich wird nur der entsprechende Speicherplatz wieder als frei deklariert.
Nach Capture.Free sehe ich im Debugger aber immernoch meine Datenstruktur in Capture, d.h. Capture ist in keinster Weise nil. Hat das seine Richtigkeit? Muss ich den selber auf nil setzen, wenn er ungültig ist?

[SirThornberry]

- Vor 1 ist Capture undefiniert (außer du hast es vorher auf nil gesetzt)
- Nach 3 ist hat Capture immer noch den gleichen Wert wie nach 1 da mit Free nur der Speicher frei gegeben wird. Wie du aber selbst bemerkt hast ist Capture ein Pointer und der zeigt immer noch auf den Speicher der durch Free frei gegeben wurde.

Du kannst aber nach 3 Capture selbst auf nil setzten. Oder du verwendest die Funktion "FreeAndNil"

[himitsu]

.Free gibt nur das Objekt frei, aber verändert nicht den "Pointer" dieser Zeigt immernoch dahin, wo früher mal das Objekt lag.

Es kommt jetzt drauf an
- entweder du läßt die Variable Capture so, wie sie ist
- oder du setzt es auf nil

PS: dafür gibt es auch die Funktion FreeAndNil
> FreeAndNil(Capture) statt Capture.Free;


Wenn du z.B. später mal abfragen willst, ob da ein Objekt existiert ,

Delphi-Quellcode:

if Assigned(Capture) then

dann mußt du es auf nil sezten.
Ansonsten isses eigentlich egal.


Und ob das Objekt (dessen Daten noch angezeigt wird), das hängt teilweise auch vom Speichermanager ab.

Der reserviert bei Windows den Speicher in größeren Blöcken und vergibt ihn in kleineren weiter.
Heißt also, daß dieser Speicher immernoch bei Windows reserviert ist, aber im DelphiMM als "frei" für die weitere Verwendung markiert wurde ... solange bis es überschieben/weitergegeben wird oder auch alles Andere in diesem Block freigegeben wurde und der DelphiMM ihn wieder an Windows zurückgibt.

[iphi]

Ok, danke für die Tipps! Dann liege ich ja nicht ganz falsch.

Zitat:

Vor 1 ist Capture undefiniert (außer du hast es vorher auf nil gesetzt)

Mein Delphi6-Compiler scheint bei Programmstart alle globalen Variablen auf Null bzw. nil zu initialisieren. Gibts dafür einen Compilerschalter? Kann man sich darauf verlassen?

Und:
Wo liegt denn der Unterschied zwischen

Delphi-Quellcode:

if Capture<>nil then ...

und

Delphi-Quellcode:

if Assigned(Capture) then

?

Ich habe bisher immer ersteres Konstrukt verwendet, daher auch meine ursprüngliche Frage.

[himitsu]

Einen Unterschied gibt es hier nicht.
Delphi macht im Prinzip auch nur eine Prüfung auf <>nil

Abgesehn bei Eventprozeduren (prozedure of object), denn dieses besteht intern aus 2 Pointern,
weswegen hier eine Prüfung auf <>nil natürlich nicht geht, wärend Assigned dieses prüfen kann.

Also im Endefekt macht sich Assigned da besser, da du dich nicht um Den Typ/Aufbau kümmern mußt
und es überall funktioniert, wo man sowas prüfen möchte.

Zitat:

Zitat von iphi

Mein Delphi6-Compiler scheint bei Programmstart alle globalen Variablen auf Null bzw. nil zu initialisieren. Gibts dafür einen Compilerschalter? Kann man sich darauf verlassen?

es kommt drauf an, wo diese Variable definiert wurde.
http://www.delphipraxis.net/internal...063919#1063919