Verständnisfrage Assigned vs nil

[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

[DasWolf]

Zitat von DieDolly:

Ich glaube wenn man mit .Free etwas freigibt, ist Assigned() False und = nil auch False.
Deswegen setze ich manuell immer alles auf nil wenn ich etwas mit Free freigebe.

Nagel mich nicht drauf fest. Bin mir unsicher.

Wenn etwas mit .Free freigegeben wird, dann ergibt die Abfrage mit Assigned() TRUE und die Abfrage auf = nil FALSE.

Wenn etwas mit FreeAndNil() freigegeben wird, dann ergibt die Abfrage mit Assigned() FALSE und die Abfrage auf = nil TRUE.

[DieDolly]

Zitat:

Wenn etwas mit .Free freigegeben wird, dann ergibt die Abfrage mit Assigned() TRUE und die Abfrage auf = nil FALSE.

Also ist Assigned() und die Prüfung auf nil nicht gleichwertig wie vermutet WENN man nur mit .Free freigibt statt FreeAndNil.

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