Verständnisfrage Assigned vs nil

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