Warum FreeAndNil so umständlich?

[negaH]

ein try finally Block ist absolut überflüssig.

Was will der Code erreichen ?

Er will sicherstellen das die Referenz auf das Object -> Variable, in jedem Falle auf nil gesetzt wird.
Tja, und dies tut der Borlandcode perfekt.

In EAX ein Zeiger auf die Variable. In EDX wird das Object geladen, dann indirekt über [EAX] die Variable auf nil = 0 gesetzt und dann das Object in EDX zerstört. Effektiv benötigt damit FreeAndNil() maximal 5 Assemblerinstruktionen.

Vergleich mit try finally Block:

Wir können mit desem maximal exakt die gleiche Funktionalität erreichen wie ohne dem try finally block. Dafür wäre diese Methode, selbst wenn keine Exceptions auftreten, wesentlich langsammer. Ja sogar störanfälliger Denn jeden CPU Takt länger den man benötigt um irgendwas zu machen, erhöht das Risiko das andere asynchrone Programmteile (IRQs zb. etc.pp) irgendwelche Informationen zerstören können.

Die Lösung von Borland ist damit perfekt und weitaus besser als ein try finally Block.

Gruß Hagen

[sakura]

Zitat von Luckie:

Warum sollte Free eine Exception auslösen? Dies könnte nur passieren, wenn das Objekt nil ist, aber das überprüft Free vorher.

Wenn das Objekt bereits entladen (Free, Destroy) wurde und nicht auf NIL gesetzt wurde, dann wird man recht schnell mit einer Exception begrüßt

......