Freigeben von Objekten

[Rabenrecht]

Eine Sache, bei der ich noch sehr unsicher bin, ist die Frage, welche Objekte man mit Free/FreeAndNil wieder freigeben sollte, und wann das nicht nötig ist.

Gibt es da ein paar allgemeine Richtlinien, an denen man sich entlanghangeln kann?

[Sherlock]

Alle Objekte die man selbst (also im Programmfluss) erzeugt, muss man auch wieder freigeben.
Ausnahme: Objekte, die in andere Objekte eingefügt werden, zB Listenelemente in eine Liste, können auch von dem Eigentümer freigegeben werden (vergleiche TObjectList.OwnsObjects), sobald dieser wiederrum von Dir freigegebn wird.
Was Du zur Designzeit auf die Form legst (und nur das) wird beim Programmende bzw. beim freigeben der Form freigegeben.

Es gibt sicher noch ein paar Feinheiten, die im Laufe dieses lesenswerten Threads von unseren Koryphäen hinzugefügt werden, aber das dürfte ein passables Basislager sein.

Sherlock

[haentschman]

Moin...:P
Im Prinzip ist es einfach...:P Was du selbst erzeugst, gibst du wieder frei. :thumb:
Ausnahmen:
* Interfaces
* TObjectListen wenn OwnObjects = True

...usw.

[MichaelT]

GUI Komponenten musst du nicht freigeben. Die werden intern verwaltet.

Bei Formularen macht Release Sinn.

Zitat:

Zitat von Rabenrecht (Beitrag 1361903)

Eine Sache, bei der ich noch sehr unsicher bin, ist die Frage, welche Objekte man mit Free/FreeAndNil wieder freigeben sollte, und wann das nicht nötig ist.

Gibt es da ein paar allgemeine Richtlinien, an denen man sich entlanghangeln kann?

[Christian Seehase]

Moin Rabenrecht,

ich würde diese Vorgehensweise nicht nur auf Objekte einschränken,
sondern auf alle Arten von Resourcen ausdehnen.

Um sicher zu gehen, dass man nichts vergisst wieder freizugeben,
sollte man, wenn man eine Resource belegt, auch gleich deren
Freigabe an der Richtigen Stelle unterbringen.
Meist gibt einem die Sprache hierfür schon die entsprechenden
Strukturen schon an die Hand.
Beispiele:
Eine Unit kann einen initialization und einen finalization
Abschnitt haben.
Eine Resource, die innerhalb der Unit (damit, ggf., innerhalb des
Programms zur Verfügung stehen soll) wird im initialization
Abschnitt belegt. Wenn man dann gleich im finalization-Abschnitt
die Freigabe einträgt kann man das später nicht vergessen.

Bei Klassen wären das dann constructor und destructor.

Innerhalb einer Methode/Funktion/Prozedur wird man häufig
die Try/Finally-Blöcke verwenden.

Delphi-Quellcode:

Resource belegen
try
  mit der Resource arbeiten
finally
  resource freigeben
end;

Da es wichtig ist hier nicht die Übersicht zu verlieren,
sollte man auch nie ein Objekt als Rückgabewert einer
Methode verwenden, wenn dieses erst dort erzeugt wird,
ausser die Klasse aus der die Methode stammt verwaltet
die Objekte selber (z.B. TListView.AddItem)

An welchen Stellen man Resourcen belegt und wieder freigibt
mache ich davon abhängig, wie und wie oft diese jeweils
benötigt werden.
Wenn ich, z.B., in den Methoden eines Formulares häufig eine
TStringList benötige kann es sinnvoll sein diese als Feld des
Formulares zu deklarieren und dann jeweils zu leeren statt
sie immer wieder neu zu erzeugen und freizugeben.
sinnvoll sein, diese

[Rollo62]

Bei Free and FeeAndNil kannst du dir die Partei aussuchen.
Da gibt es noch vereinzelte Grabenkämpfe:
http://stackoverflow.com/questions/3...-or-freeandnil
http://stackoverflow.com/questions/3...n-a-destructor

Die Tendenz ist aber Free sollte reichen, auch wenn Emba FreeAndNil ausgiebig intern benutzt.

Und: Es gibt ja noch DisposeOf.
Das könnte interessant werden wenn du mobil mit ARC programmiert.

Rollo

[Rabenrecht]

Das sind schon mal sehr hilfreiche Antworten :-)

Generell aber nur Objekte, die man mit Create erzeugt hat, oder?

Was wäre zb. mit:

Delphi-Quellcode:

procedure someMethod(Column:TColumn);
var
  Field : TField;
begin
  Field := Column.Field;
end;

Muss man hier Field.Free aufrufen?
Es wird hier ja nicht wirklich Speicher reserviert.

[Der schöne Günther]

Zitat:

Zitat von Rabenrecht (Beitrag 1361923)

Es wird hier ja nicht wirklich Speicher reserviert.

Richtig. Deine lokale Variable "Field" ist nur eine Referenz auf "Column.Field". Du hast nichts "erzeugt".

[Sherlock]

Ja, zu FreeAndNil gibt es viele Referate.

Sherlock