FreeAndNil macht Probleme

[himitsu]

Zitat von jfheins:

Du hast ja Free nicht überschrieben (weil unmöglich - überschreiben geht ja nur bei virtuellen Methoden)

Free braucht auch nicht viruell zu sein. Am Ende wird sowieso Destroy aufgerufen, also reicht das vollkommen aus.
Wenn auf einem Pfad mehrere Methoden überscheibbar sind, dann kommt eh nur Chaos raus wenn ein Teil hier und ein Teil da.

Sowas gibt es teilweise in der VCL/RTL und das macht keinen Spaß.
Bei Constructoren einiger Klassen, im TStream mit SetSize und Co. oder z.B. beim Assign und AssingTo des TPersistent/TComponent.
Abgesehn davon dass man sich dann selbst nur schwer entscheiden kann, wo man nun was rein machen muß.


Durchgestrichen? Hab ich hier doch garnichts, aber wenn, dann wäre es ein [S]Geheinis[/S].
Oder meinst das Unterstrichen der Akronyme ala BBCode?

[Benmik]

@jfheins: Das heißt, dass durch den Umweg über das Casting zu TObject (damit in jedem Fall Nil geschieht) direkt die Original-Methode Free von TObject aufgerufen und dadurch mein Free (mangels override) umgangen wird? Tricky, würde ich sagen. Warum ist denn dann TObject.Free nicht virtuell? Jedenfalls wieder eine Erkenntnis.
Von Destroy hatte ich die Finger gelassen, weil in der OH steht, man solle Destroy nicht direkt aufrufen. Aber es stimmt, von nicht überschreiben stand da nichts.

@Himitsu: Mist, das hatte ich bei meiner Suche nicht gesehen ausprobiert! Danke!

[jfheins]

Zitat von Benmik:

@jfheins: Das heißt, dass durch den Umweg über das Casting zu TObject (damit in jedem Fall Nil geschieht) direkt die Original-Methode Free von TObject aufgerufen und dadurch mein Free (mangels override) umgangen wird?

Ja, genau. Das passiert bei allen Methoden, die nur verdeckt werden. (Verdecken = Neue Definition aber ohne override)

=> Verdecken sollte vermieden werden.

Zitat:

Tricky, würde ich sagen. Warum ist denn dann TObject.Free nicht virtuell? Jedenfalls wieder eine Erkenntnis.

Weil .Destroy ja schon virtuell ist damit genau eine einzige Stelle existiert, wo man Freigabecode unterbringen sollte.

Free hingegen macht ja nur den nil check mehr, und damit war die Methode aus Sicht der Entwickler einfach fertig.

[Benmik]

Einleuchtend. Da hantiert man eine Ewigkeit mit Free und kommt erst jetzt zu einem Blick hinter die Kulissen.

Wie gesagt, ich hatte Destroy aufgrund der Warnung in der OH immer so etwas wie eine Methode (so wie eine abstrakte) gesehen, die man nicht direkt anfassen sollte.

[himitsu]

Zitat:

Von Destroy hatte ich die Finger gelassen, weil in der OH steht, man solle Destroy nicht direkt aufrufen

Genau, du sollst Destroy nicht aufrufen, sondern eben Free oder FreeAndNil verwenden,
aber das hat nichts mit dem Überschreiben zu tun. Soll was beim Freigeben gemacht werden, dann kommt es ins Destroy rein, mit Override.

Extern benutzt du Free (weil dort das If-Assigned eingeaut ist),
aber intern kommt der Code ins Destroy.


Ein paar Beispiele, warum "überdecken" statt Überschreiben selten eine gute Idee ist.
Bei TStrings und TStream verwentet man meistens die Basisklasse für Varisblen und Parameter, damit man die Funktion unabhängig von der Quelle implementieren kann, aber beim Erstellen wird dann dir Endklasse benutzt. Sind da Methoden nur verdeckt, dann werden sie nie verwendet, siehe dein Free.

[Benmik]

Ich hatte gerade vor kurzer Zeit etwas über Verdecken und Überschreiben gelesen, und es war mir nicht so richtig klar geworden, warum Verdecken jetzt soooo schlimm ist. Die Praxis ist halt der beste Lehrmeister. Insbesondere die Tatsache, dass ich diese Problematik nie an dieser Stelle vermutet hätte. Dabei kannte ich den Emba-Code und hatte bei SO gelesen, warum man den Umweg über eine Tempvariable gegangen ist.

[himitsu]

Ja, die TempVariable ist nur, weil FreeAndNil eben "erst Nil und dann Free" macht.