Verständnisfrage Assigned vs nil

[Delbor]

Hi zusammen
Was ist der Unterschied zwischen einer Abfrage eines Objektes auf Nil bzw. assigned?

Delphi-Quellcode:

  if Assigned(FSQLiteFolderList) then
  if FSQLiteFolderList = nil then

Assigned mag zwar eleganter klingen, aber das ist wohl kaum dessen Sinn.

Gruss
Delbor

[DieDolly]

Ich glaube wenn man mit

Delphi-Quellcode:

.Free

etwas freigibt, ist

Delphi-Quellcode:

Assigned()

False und

Delphi-Quellcode:

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

[Klaus01]

..laut diesem hier
ist not assigned() mit nil gleichwertig.

Grüße
Klaus

[scrat1979]

Zitat:

Zitat von DieDolly (Beitrag 1452498)

Ich glaube wenn man mit

Delphi-Quellcode:

.Free

etwas freigibt, ist

Delphi-Quellcode:

Assigned()

False und

Delphi-Quellcode:

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

Ich denke nil müsste dann true sein, oder?

[DieDolly]

Zitat:

Zitat von scrat1979 (Beitrag 1452502)

Ich denke nil müsste dann true sein, oder?

True False False True True... eins davon. Logische Verknüpfungen waren noch nie mein Ding.

[Delbor]

Hi zusammen

Danke für eure Antworten. Offenbar habe ich asssigned etwas überschätzt.

Gruss
Delbor

[DieDolly]

Wenn du deine Variable nach Free immer manuell auch auf nil setzt ist alles gut.

[Delbor]

Hi Dolly

Zitat:

Zitat von DieDolly (Beitrag 1452505)

Wenn du deine Variable nach Free immer manuell auch auf nil setzt ist alles gut.

Da müsste man FreeAndNil verwenden...

Gruss
Delbor

[Dalai]

Folgende Abfragen sind gleichwertig:

Delphi-Quellcode:

if Assigned(Objekt) then
if Objekt <> nil then

Erstere Variante ist IMO etwas einfacher zu lesen, wenn man gerade in einem Editor ohne Syntaxhervorhebung unterwegs ist, in dem auch noch die Schrift etwas klein ist und man so Schwierigkeiten hat, schmale Zeichen sauber zu erkennen. Aber grundsätzlich soll jeder das verwenden, was er/sie mag.

Grüße
Dalai

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

Zitat von Uwe Raabe (Beitrag 1452510)

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:

Zitat von bcvs (Beitrag 1452511)

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:

Zitat von DieDolly (Beitrag 1452498)

Ich glaube wenn man mit

Delphi-Quellcode:

.Free

etwas freigibt, ist

Delphi-Quellcode:

Assigned()

False und

Delphi-Quellcode:

= 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

Delphi-Quellcode:

.Free

freigegeben wird, dann ergibt die Abfrage mit

Delphi-Quellcode:

Assigned()

TRUE und die Abfrage auf

Delphi-Quellcode:

= nil

FALSE.

Wenn etwas mit

Delphi-Quellcode:

FreeAndNil()

freigegeben wird, dann ergibt die Abfrage mit

Delphi-Quellcode:

Assigned()

FALSE und die Abfrage auf

Delphi-Quellcode:

= 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 (

Delphi-Quellcode:

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.

Delphi-Quellcode:

o <> nil

=

Delphi-Quellcode:

Assigned(o)

Delphi-Quellcode:

o = nil

=

Delphi-Quellcode:

not Assigned(o)

und nach

Delphi-Quellcode:

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.

[DasWolf]

Zitat:

Zitat von Luckie (Beitrag 1452572)

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.

Es gibt nicht nur Schwarz und Weiß, wie sowas hier:

Delphi-Quellcode:

procedure Test;
var
  o: TMyObj;
begin
  o := TMyObj.Create;
  try
    ...
    ...
  finally
    o.Free;
  end;
end;

Deshalb rate ich jedem, immer zu prüfen, egal ob es unnötig erscheint oder nicht.

[Sherlock]

Die Diskussion hatte IMHO der gute Nick Hodges in seinem Blog gestartet beendet. Aber Multithreaded glaube ich nicht an die pauschale Gültigkeit dieser Aussage.

Sherlock

[himitsu]

Eine Variable mit einem Objekt während der Lebenszeit dieser Variable.
Free reicht, wenn nach dem Free nicht mehr auf die Variable zugegriffen wird.
Gibt es aber mehrere Stellen wo erstellt oder freigegeben wird, dann muß die Variable auch auf nil gesetzt werden.

Eine Variable wo während der Laufzeit mehrere Objekte drin gespeichert/verlinkt sind und zwischendurch auch mal nichts drin stehen kann, dann ebenfalls nil setzen.
Ob nun FreeAndNil oder Free plus :=nil das sei jedem selbst überlassen.

Immer FreeAndNil, falls ich mal irgendwo scheiße bau und nicht mehr weiß was ich wo mache = schwachsinn sinnlos, siehe Nicks Blog.

Aber hier *muss* nil gesetzt werden,
am Besten via FreeAndNil, falls es im Free/Destroy knallen kann, sonst knallt es bestimmt nochmal beim letzten Free und schrottet mir die originale Fehlermeldung/Fehlerposition.

Delphi-Quellcode:

o := TMyObj.Create;
try
  ...
  FreeAndNil(o);
  ...
finally
  o.Free;  // hier ist intern ein IF ASSIGNED(SELF) drin
end;

Delphi-Quellcode:

o := nil;  // genauso, wie das hier nicht vergessen werden darf
try
  ...
  o := TMyObj.Create;
  ...
  FreeAndNil(o);
  ...
finally
  o.Free;  // hier ist intern ein IF ASSIGNED(SELF) drin
end;

@DasWolf: Jupp, also wie gesagt, wird nach dem Free nochmal irgendwie auf den Inhalt zugegriffen, dann NIL nicht vergessen zu setzen.


Und auf die grauenhaften Besonderheiten im NextGen will jetzt niemand eingehen. (ich sag nur "Free" macht garnichts und Objekte werden nicht da freigegeben wo und wann ich es will/erwarte)



PS: Wäre der Compiler intelligent genug und täte beim .Free oder .Destroy den Status der Variable zurück auf "nicht initilisiert" setzen,
wann gäbe es hier

Delphi-Quellcode:

x.Free;
if Assigned(X) then 

// oder
x.Free;
x.irgendwas;

eine der bekannten Warnungen, beim nachfolgenden Zugriff. (Variable nicht initialisiert)

[freimatz]

Bitte lasst doch die Diskussion, die wurde schon gefühlt tausendfach geführt.
Es geht hier doch um Assigned vs nil

[himitsu]

Zitat:

Zitat von hoika (Beitrag 1452575)

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.

Objekte liegen nicht auf dem Stack (außer manchmal deren Variable),
aber ja, wenn der speichermanager das Block noch nicht freigeben und auch noch nicht anders wiederverwendet hat, dann stimmt es natürlich.

PS: Darum gibt es in einigen Speichermanagern/Debuggingtools eine Option ala "markiere freigegeben Speicher" (fülle mit hübschen Bytes), bzw. notfalls auch "leere/nulle freigegebenen Speicher", um solche Fehler leichter finden zu können.
(z.B. im großen FastMM)
Aber bei Speicher wurde bereits neu vergeben, dagegen ist ein Kraut gewachsen, drum hilft sowas nur bedingt. (außer man bringt den Speichermanager dazu den Speicher nicht freizugeben oder neuzuvergeben, aber dann wird der Speicher schnell voll)

[Rollo62]

Also ich habe eine einfache Regel: IMMER Assigned() benutzen ...

Wozu = nil benutzen ? Das bringt doch nur zusätzliche Fehlermöglichkeiten rein.

Der einzige Nachteil ist, das mehr Buchstaben zu schreiben sind :stupid:

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1452623)

Also ich habe eine einfache Regel: IMMER Assigned() benutzen ...

Sieh mal an, ich habe da eine ganz andere Sichtweise: Assigned verwende ich nur bei Methodenzeigern, weil ich dann gleich sehe, dass es ein Methodenzeiger ist.
Ist halt alles Geschmackssache...

[Rollo62]

Ja ich bin wohl noch jemand der versucht allen Dingen eindeutige Namen zu geben,
deshalb sehe ich sofort ob es Methoden, Felder, Parameter, etc..

Aber so hat eben jeder seine Macke :stupid:

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1452648)

Ja ich bin wohl noch jemand der versucht allen Dingen eindeutige Namen zu geben,
deshalb sehe ich sofort ob es Methoden, Felder, Parameter, etc..

Na ja, ein Feld oder Parameter kann ja sowohl eine Objekt-Instanz als auch ein Methodenzeiger sein. Der Name AfterPost kann somit sowohl eine Methode als auch einen Event bezeichnen ohne dass an der Benennung auf den ersten Blick etwas auszusetzen wäre. Setzt man auch noch das vorgestellte F für Felder oder A für Parameter voraus, dann kann je nach Kontext FAfterPost aber auch eine Instanzvariable sein, die zu einer Gruppe von ähnlichen Variablen gehört. Der Name einer Variablen sagt ja erstmal nichts über den Typ aus. Soll es ja auch nicht, denn sonst müsste ich ja beim Ändern des Typs immer den Namen mitändern.

[p80286]

Zitat:

Zitat von Rollo62 (Beitrag 1452623)

Also ich habe eine einfache Regel: IMMER Assigned() benutzen ...

Wozu = nil benutzen ? Das bringt doch nur zusätzliche Fehlermöglichkeiten rein.

Ich sehe das ähnlich.

z.B.

Delphi-Quellcode:

var
  MyFileList : Tstringlist;
....

if assigned(Myfilelist) then
  Myfilelist.Clear
else
  MyFilelist.create;
// mach irgendwas

MyFilelist.......// irgendwas oder auch nichts

Würde ich auf NIL testen müßte beim ersten Eintritt sichergestellt sein daß eine Initialisierung mit NIL vorgenommen wurde. Ebenso müßte immer ein .FreeandNil durchgeführt werden, denn ein einfaches .Free ist u.U. zu wenig.

Gruß
K-H

Nachtrag:
Ich weiß daß es einen Beitrag gab der begründete warum FreeandNil nicht optimal ist. Aber bisher hab ich nur die gegenteilige Aussage gefunden und einmal "schon wieder FreeandNil" Augenrollen.

[Fritzew]

Zitat:

Zitat von p80286 (Beitrag 1452689)

Ich sehe das ähnlich.

z.B.

Delphi-Quellcode:

var
  MyFileList : Tstringlist;
....

if assigned(Myfilelist) then
  Myfilelist.Clear
else
  MyFilelist.create;
// mach irgendwas

MyFilelist.......// irgendwas oder auch nichts

Würde ich auf NIL testen müßte beim ersten Eintritt sichergestellt sein daß eine Initialisierung mit NIL vorgenommen wurde. Ebenso müßte immer ein .FreeandNil durchgeführt werden, denn ein einfaches .Free ist u.U. zu wenig.

Gruß
K-H

Äh das must Du jetzt erläutern.....

Zitat:

Würde ich auf NIL testen

Delphi-Quellcode:

if assigned(Myfilelist) then

ist genau das selbe wie

Delphi-Quellcode:

if Myfilelist<>nil  then

und wie soll assigned helfen bei FreeAndNil und .Free? Das eine hat doch mit dem anderen nichts zu tun?

[Uwe Raabe]

Folgender Code:

Delphi-Quellcode:

var
  instance: TObject;
begin
  if Assigned(instance) then;
  if instance <> nil then;
end;

ergibt compiliert (ohne das Lead-In/Out der Methode):

Delphi-Quellcode:

Unit475.pas.37: if Assigned(instance) then;
005FD1D0 837DF800         cmp dword ptr [ebp-$08],$00

Unit475.pas.38: if instance <> nil then;
005FD1D4 837DF800         cmp dword ptr [ebp-$08],$00

[p80286]

Ich muß Abbitte leisten:stupid:
nach einem

Delphi-Quellcode:

liste.Free

ist ein

Delphi-Quellcode:

Assigned(liste

) true und ein

Delphi-Quellcode:

liste=NIL

natürlich false.

Dementsprechend ist ein .FreeandNil (falls anwendbar) einem .Free vorzuziehen falls die Möglichkeit besteht, das das Objekt noch einmal genutzt wird.

Gruß
K-H

[himitsu]

Zitat:

Delphi-Quellcode:

else
  MyFilelist.create;

*peng*

[TiGü]

Zitat:

Zitat von himitsu (Beitrag 1452796)

Zitat:

Delphi-Quellcode:

else
  MyFilelist.create;

*peng*

Feuer und Mistgabeln! :warn:

[Rollo62]

Ich kanns mir nicht verkneifen dieses alte Thema nochmal hochzuholen.
Weil es dazu hier eine sehr schöne und komplette Beschreibung gibt.