Verständnisfrage Assigned vs nil

[Uwe Raabe]

Bei Abfragen von Objekten sind die Abfragen auf nil und auf Assigned gleichwertig. Anders sieht es z.B. bei Events aus. Man kann eine Event-Variable (so wie jeden Methodenzeiger) nicht auf nil abfragen. Dafür ist dann Assigned gedacht.

Delphi-Quellcode:

procedure TCustomForm.Paint;
begin
  if Assigned(FOnPaint) then FOnPaint(Self);
end;

[bcvs]

Zitat von Uwe Raabe:

Anders sieht es z.B. bei Events aus. Man kann eine Event-Variable (so wie jeden Methodenzeiger) nicht auf nil abfragen.

Wieso nicht? Ich hatte immer gedacht, das wäre auch da gleichwertig. (Rein interessehalber)

[Uwe Raabe]

Zitat von bcvs:

Wieso nicht? Ich hatte immer gedacht, das wäre auch da gleichwertig. (Rein interessehalber)

Probier's aus!

[DeddyH]

Man könnte ja auch einfach mal die Doku bemühen.

[hoika]

Hallo,
Tipp: Beim Zuweisungstest von Objektereignissen und -prozeduren können Sie nicht auf nil testen. Dazu müssen Sie Assigned verwenden.

Da steht es

[DeddyH]

Sag ich ja

[himitsu]

Delphi-Quellcode:

procedure TCustomForm.Paint;
begin
  if TMethod(FOnPaint).Code <> nil then FOnPaint(Self);
end;

Wer will, der kann alles.
Methoden-Zeiger bestehen intern aus zwei Pointern (auf die Prozedur und auf das Object/Self).
Aber Assigned kennt die Unterschiede und nimmt dann die passende Prüfung vor.

Assigned und <>nil sind gleich, egal ob man mit Free oder FreeAndNil arbeitet.
Bei Free bleibt halt nur der nun "ungülige" Zeiger in der Variable drin, weswegen man das prüfen kann was man will.

Delphi-Quellcode:

obj.Free;
obj := nil;

FreeAndNil macht hier aber erst nil und dann Free (mit temporäter Variable dazwischen), damit wenn es im Free (Destroy) knallt, die Variable dennoch auf nil gesetzt wird/wurde.

Noch mehr Spaß macht es bei den generischen References (reference to procedure ... die Zeiger wo Prozeduren und Methoden drin sein können),
denn da hast du ein "geheimes" Interface, wo dann der Zeiger drin ist.


@DasWolf
Versuch dir nicht zu merken wie es unterschiedlich ist, sondern merk es dir so, dass es gleich ist.

o <> nil = Assigned(o)
o = nil = not Assigned(o)
und nach o.Free ist eine Variable ungülig, also will man nachher auf nil/Assigned prüfen, dann muß auch auf NIL gesetzt werden (z.B. durch FreeAndNil).

[DeddyH]

Nochmal aus der Doku:

Zitat:

Hinweis:Assigned kann keine hängenden Zeiger erkennen – d.h. Zeiger, die auf keine gültigen Daten mehr verweisen, aber dennoch nicht nil sind. In dem Codebeispiel für Assigned (SystemAssigned) wird von Assigned nicht erkannt, dass P nicht gültig ist.

Die entsprechende Variable enthält ja nach dem Freigeben weiterhin eine Speicheradresse, nur ist dort nicht mehr das drin, was vorher drin war. Erst durch Setzen von nil wird kenntlich gemacht, dass diese Adresse nicht mehr gilt.

[Luckie]

Wenn ich ein Objekt nach der Freigabe im Code nachher auf Nil testen muss, dann habe ich was falsch gemacht. Wir hatten hier mal die Diskussion warum FreeAndNil schlechter Stil ist. Vielleicht findet die noch jemand. Da würde das sehr schlüssig erklärt von einem Mitglied.

[hoika]

Hallo,

Zitat:

weiterhin eine Speicheradresse, nur ist dort nicht mehr das drin,

Einspruch, setzt testweise einen Breakpoint genau dahinter,
der Zugriff auf das freigegebene Objekt kann noch funktionieren,
gerade, wenn es auf dem Stack liegt (lokales Objekt).

Es muss aber auch nicht funktionieren.