Webinar FreeAndNil

[freimatz]

Hm, im Erklären bin ich recht schlecht, aber ich versuchs.
Vorab, das "meistens" ist in dem Fall vielleicht doch zu hoch gegriffen. Bei unserer Applikation gilt es auf jeden Fall, auch eher wenn es um die FreeAndNil-Problematik geht.

Ein string ist (vereinfacht) recht allgemein eine Folge von Zeichen. Das gilt dann auch für die TStringList.
In der Entwicklung von Software ist es immer gut möglichst die Typen so zu benennen wie sie Dinge in der Realität auch sind. Der Name "string" ist dann meist allgemeiner als nötig. So wäre z.B. eine TElementIdList aussagekräftiger als eine TStringList. Man bekommt dann auch die Vorteile der Typsicherheit.
Was ich auch schon oft sah ist dass alles Mögliche in einen String gepackt wurde, nur damit man eine TStringList verwenden konnte. Ich habe das früher auch gemacht, seit es auch in Delphi Generics gibt, sehe ich den Grund nicht mehr dazu.

[DeddyH]

Um eine Liste von Strings zu verwalten, ist eine TStringList doch die beste Option. Nur wenn man sie für andere Daten missbraucht, kann man evtl. von einer fehlerhaften Architektur sprechen.

[SearchBot]

Ich finde das Thema toll, weil ich genau so ein Problem gerade habe und nicht weiß, wieso das so ist.

Zum Hintergrund:
Ich habe einen "Out of memory"-Fehler bekommen. Also habe ich in den Bereich hineingesehen und bemerkt (irrtümlich aber wie es nun scheint), daß ich viel mit .create mache, aber am Ende gar kein .free setze.

Also habe ich die Methoden ergänzt um jeweils try .. finally
Es sind solche Dinge:

Delphi-Quellcode:

var json, p1, p2: TJSONObject;
    jsonArr: TJSONArray;
    JsonToSend : TStream;

In dieser Procedure baue ich also eine JSON-Struktur aus, die ich dann an ein Gerät sende. Das funktioniert soweit prima (bis halt irgendwann Out of Memory kommt).
Am Ende bin ich dann auf die Idee gekommen, ich sollte alles, was ich mit .create in der Procedure erstelle, auch wieder freigeben.

Zwischendrin habe ich auch mal sowas geschrieben:

Delphi-Quellcode:

  if isCassette<>'TX' then
   p1 := TJSONObject.Create
  else
   p1:=json; //gleiche Ebene

Und am Ende dann also (wobei ich in vielen Quelltextbeispielen am Ende keine Freigaben gesehen habe; mein Memoryleak scheint also woanders in der Verwendung mit JSON zu liegen) geschrieben:

Delphi-Quellcode:

 finally
  FreeAndNil(JsonToSend);
  FreeAndNil(jsonArr);
  FreeAndNil(p1);
  FreeAndNil(p2);
  FreeAndNil(json);
 end;

In der umgekehrten Reihenfolge habe ich jeweils .create gemacht (also erst json, dann die p1,p2 und dann jsonArr und zuletzt JsonToSend). Ich nehme an, daß die Reihenfolge der Freigabe auch wichtig ist.

Da habe ich dann aber eine "Ungültige Zeigeroperation" bekommen.
Ich habe dann die Exception eingegrenzt zu FreeAndNil(json). json ist ein TJSONObject. Es scheint aber trotz seines naheliegenden Namens keine Ableitung von TObject zu sein, weil es dort knallt!?

In der Hilfe zu "FreeAndNil(var Obj)" ist zu lesen: "Warnung: Obj muss eine Instanz einer von TObject abgeleiteten Klasse sein" - aha, und was wäre die Folge wenn nicht?? Und woher weiß ich welche Objekte, mit denen ich .create mache, von TObject abgeleitet sind?! Die Hilfe ist oft nicht wirklich hilfreich. Bin so froh, daß es dieses Forum hier gibt.

Habs dann so versucht:

Delphi-Quellcode:

 finally
  JsonToSend.Free;
  jsonArr.Free;
  json.Free;
  p1.Free;
  p2.free;
 end;

Knallt trotzdem bei json.free

Kann ich denn überhaupt .Free machen, wenn die json bereits NIL wäre?
Müsste ich dann vorsichtshalber "if assigned(json) then json.free" schreiben?
Oder wäre "if json<>nil then json.free" besser?

Bin verwirrt.
Was mache ich falsch und warum?

[DeddyH]

Beim Aufruf von Free bzw. FreeAndNil musst Du nicht vorher auf Assigned oder nil prüfen, das tun die Methoden bereits intern, im Gegensatz zu Destroy. Zu Deinem Problem: falls das JSONObject Teil eines anderen JSON-Objekts ist, kümmert sich dies bereits um die Freigabe, mit der Zuweisung holst Du Dir dann lediglich einen weitere Referenz, aber keine neue Instanz. Rufst Du also hier Free auf einer bereits vom "Eltern-JSON" freigegebenen Referenz auf, knallt es natürlich, da hilft auch kein FreeAndNil.

[Sherlock]

Die ganze Diskussion zeigt doch nur eines: Die einzige Strafe, die die Verwendung von FreeAndNil mit sich bringt ist ein missbilligender Blick des Kollegiums. Es gibt keine Performance Strafe, es gibt keine Fehler. Es ist alles gut. Und damit kann ich wunderbar leben.

Sherlock

[jaenicke]

Zitat von Sherlock:

Es gibt keine Performance Strafe

Ganz kostenlos ist der Aufruf nicht, aber solange man das nicht in einer Schleife sehr oft aufruft, spielt das keine Rolle. Das try..finally Handling dürfte da ohnehin teurer sein.

[himitsu]

FreeAndNil hat doch kein Try-Finally drin?

Drum macht es ja eigentlich NilAndFree, im sich das Try-Finally zu sparen.



Einzig, wo es im FreeAndNil Probleme geben könnte, wenn im Destructor oder etwas darin Aufgerufenem oder anderem Freigegeben irgendwo auf diese (globale) Variable zugegriffen würde.
z.B. im OnDestroy der Form auf die Form-Variable, anstatt auf Self.

Hier ist die Variable ja schon vorher NIL und es würde dann knallen.


Genau aus dem Grund setzt Application.FormCreate schon vor dem Constructor/OnCreate die Variable, falls jemand beim Laden auf diese Variable zugreift.
und automatisch werden die FormVariablen nicht genilt, weswegen es dann beim Freigeben auch nicht mehr knallt.