Array korrekt freigeben

[QuickAndDirty]

Zitat von Uwe Raabe:

Delphi-Quellcode:

  { aber hier ist eine Finalisierung für MyPtr^ notwendig, andernfalls bleibt der string bestehen }
//  Finalize(MyPtr^);

Holy shit.
Ich habe nie New+Dispose benutzt. Und ich dachte immer longstrings kümmern sich selbst um sich und da muss ich mir keine sorgen machen.
Also für Records mit fester größe immer new und dispose nutzen....hm

Zitat von himitsu:

und New+Dispose wie eine lokale managed Variable, bzw. wie Create und Destroy zum Objekt-Feld.

Dispose darf man dann aber auch nur einmal aufrufen?

Zitat von woodie:

ich habe im Beispiel nur alle 3 Varianten aufgeführt:

Code:

Setlength(AArray,0);
Finalize(AArray);
AArray:=nil;

um 'sicher' zu gehen, normalerweise nutze ich nur Setlength(AArray,0);

Die Frage ist aber immer noch, warum es mir von FastMM5 als Leak angezeigt wird.

Vielleicht brauchst du so eine Demo mit Log des Refcount wie Uwe Raabe sie für die verschiedenen New+Dispose, GetMem+Freemem und Declare + :=nil gemacht hat
Nur eben für diesen dreifach free.

[himitsu]

Zitat von QuickAndDirty:

Dispose darf man dann aber auch nur einmal aufrufen?

Per se ja.

Delphi-Quellcode:

procedure Dispose(P);
begin
  Finalize(P);
  FreeMem(P);
end;

Leider ist hier kein P := nil; enthalten, wie beim FreeAndNil,
aber wenn du es selbst danach machst, dann wäre ein Mehrfachaufruf OK.

Delphi-Quellcode:

New(P);
...
Dispose(P);
P := nil;

Und das Finalize selbst.
Ich bin mir nicht sicher, ob es "vollständig" den speicher nullt (hab das Gefühl, für einige Typen wird das nicht gemacht),
aber wenn nicht, dann würde hier ein ZeroMemory/FillChar nach dem Finalize helfen, damit es mehrmals aufgerufen werden kann.

[Uwe Raabe]

Zitat von QuickAndDirty:

Ich habe nie New+Dispose benutzt. Und ich dachte immer longstrings kümmern sich selbst um sich und da muss ich mir keine sorgen machen.
Also für Records mit fester größe immer new und dispose nutzen....hm

Ich habe schon ewig keine Pointer auf Records mehr benutzt und somit komme ich auch nicht in die Verlegenheit, für Records Speicher zu reservieren und diesen freizugeben. In der Regel kann man solche Fälle heutzutage anders lösen.

[TiGü]

Zitat von Der schöne Günther:

Vielleicht im Debugger noch einen der Strings in Visualizer gehabt? Da kann sowas passieren.

Hand hoch, wer auch schon mal einen halben Tag auf der Suche nach derartigen Speicherlecks verbracht hatte und sich immer wunderte, warum der FastMM beim Kollegen (ohne derartiges Untersuchungsobjekt in der Watch List) das Problem nicht anzeigte!