Objekte / Freigaben / Free / Nil

[Alex_ITA01]

@baumina:

Zitat:

Ich würde im Destroy lieber rückwärts freigeben, also statt for i:=0 to Count-1 lieber for i:=Count-1 downto 0.

Darf ich fragen warum?

@Uwe Raabe:
Was müsste ich denn machen, um das Object[i] als solches auch freizugeben und auf Nil zu setzen?

Gruß

[DeddyH]

FreeAndNil(Objects[i]); Wobei mir nicht klar ist, wozu genilt werden soll, wenn die Liste danach eh futsch ist.

[mkinzler]

Darf ich fragen warum? weil sich u.U. durch Löschen der Index ändern könnte

[Union]

Zitat von Alex_ITA01:

@baumina:

Zitat:

Ich würde im Destroy lieber rückwärts freigeben, also statt for i:=0 to Count-1 lieber for i:=Count-1 downto 0.

Darf ich fragen warum?

@Uwe Raabe:
Was müsste ich denn machen, um das Object[i] als solches auch freizugeben und auf Nil zu setzen?

Gruß

Weil die Liste jedesmal schrumpft und Du die Anzahl der Elemnte überschreitest. Also entweder mit for ... downto oder mit while count > 0

[DeddyH]

Seit wann schrumpft eine TStringlist, wenn ich deren Objekte freigebe?

[Der schöne Günther]

In dem Fall vielleicht nicht. Aber angenommen, man iteriert rein über den Index über eine Liste und meineListe.EntferneEintragMitNummer(34) lässt nun alles nach Stelle 34 aufrücken? Dann doch wohl.

[Namenloser]

Zitat von Alex_ITA01:

@baumina:

Zitat:

Ich würde im Destroy lieber rückwärts freigeben, also statt for i:=0 to Count-1 lieber for i:=Count-1 downto 0.

Darf ich fragen warum?

Vielleicht kann es nicht schaden, sich das zur Gewohnheit zu machen, denn wenn man z.B. statt FreeAndNil Delete aufruft, bekommt man sonst Probleme. Aber eigentlich ist es hier unnötig...

Edit: Eine andere Sache, die mir an dem Code hier auffällt, ist allerdings die völlige Sinnlosigkeit von FreeAndNil. Die Prozedur gibt dir hier nur falsche Sicherheit, denn alles was sie tut, ist, die lokale Variable auf nil zu setzen. In der Liste selbst ändert sich nichts. Ach das Prüfen mit Assigned ist daher völlig sinnlos und erschwert höchstens die Fehlersuche.

[baumina]

Zitat von Alex_ITA01:

@baumina:

Zitat:

Ich würde im Destroy lieber rückwärts freigeben, also statt for i:=0 to Count-1 lieber for i:=Count-1 downto 0.

Darf ich fragen warum?

Hast recht, müsste bei einer StringList egal sein wie rum, da sich ja die Größe der Liste beim Object.Free nicht verändert.

EDIT : Aber solltest du im Destroy nicht einen TypeCast auf TMyOwnObject machen? FreeAndNil(TMyOwnObject(Objects[i]))

[Alex_ITA01]

Ok, danke für die Hinweise.
Mich interessiert natürlich jetzt noch das Thema mit dem FreeAndNil(tmpObj) und dem Object was noch später verfügbar ist.

Bzw. Wie gibt man die Objecte innerhalb der Liste denn richtig frei?

Gruß

[Uwe Raabe]

Du kannst dir bei XE4 die Ableitung von TStringList sparen, wenn du deren property OwnsObjects auf true setzt. Damit gibt die Liste beim Löschen von Elementen und somit auch im eigenen Destroy auch die Objects frei.