FreeAndNil macht Probleme

[Benmik]

OK, folgende Änderungen:

Delphi-Quellcode:

      procedure Clear;
      destructor Destroy; override;
      constructor Create;

Delphi-Quellcode:

destructor TEXIF.Destroy;
begin
  FreeAndNil(FDStream);
  inherited;
end;

Jetzt meldet sich FastMM mit der schon bekannten langen Liste von Lecks, obwohl es kein FreeAndNil gibt. Mit dem einfachen bisherigen Free sagt FastMM nichts.

EDIT: Bitte um Verzeihung, funktioniert doch. In Destroy hätte viel mehr stehen müssen als nur der FDStream.
Ich danke euch beiden. Verstehe es aber trotzdem nicht ganz: FreeAndNil setzt die Referenz auf nil und ruft dann Free auf. Wieso muss der Compiler dann mein (?) FreeAndNil kennen?

Und nebenbei: Wie machst du den durchgestrichenen Text, Himitsu?

[jfheins]

Zitat von Benmik:

Ich danke euch beiden. Verstehe es aber trotzdem nicht ganz: FreeAndNil setzt die Referenz auf nil und ruft dann Free auf. Wieso muss der Compiler dann mein (?) FreeAndNil kennen?

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

Wenn du dir FreeAndNil anguckst, steht da:

Delphi-Quellcode:

procedure FreeAndNil(var Obj);
var
  Temp: TObject;
begin
  Temp := TObject(Obj);
  Pointer(Obj) := nil;
  Temp.Free;
end;

D.h. .Free wird auf eine Variable von Typ TObject aufgerufen. Und das ist OK, denn TObject is ja hinreichend.

Nur ohne das override wird hier auch immer TObject.Free aufgerufen. Nur bei virtuellen Methoden wird hier nachgeuckt, ob die Methode überschrieben wurde.

[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.