String freigeben nur wo?

[EWeiss]

danke dir Uwe..

Ich habe es vorher mal so versucht.

Delphi-Quellcode:

  if not Assigned(FPBuffer) then
    New(FPBuffer);
  //.....
  finalize(FPbuffer^);
  Dispose(FPBuffer);
  FPBuffer := nil;

  finalize(LineStart^);
  Dispose(LineStart);
  LineStart := nil;

Ist das gleiche Ergebnis wie bei dir.
Ich bin darauf gekommen weil du sagtest

Zitat:

Was mir auffällt ist, daß für jede Zeile im AppendToLinkedList ein New() aufgerufen wird, es aber nur ein einziges Dispose() gibt.

Es ist ja eigentlich nicht nötig jedes mal den FPBuffer neu zu erstellen wenn ich es einmal getan habe.
Doch ist nötig Deshalb nehme ich deine Lösung. Danke noch mal.

Beide Varianten melden jetzt keinen Speicherleck mehr.

Frage mich nur warum beim doppelklick in dem EurekaLog Dialog auf diese zeile gesprungen wird.
AppendToLinkedList(nReading, sBuffer); // sBuffer soll einen Memoryleak produzieren.

das irritiert doch etwas denn sBuffer kann ich dort nicht einfach löschen.

Zitat:

Zitat von DasWolf:

Zitat von EWeiss:

Wenn ich eine Variable als integer definiere dann ist automatisch wenn nichts anderes angegeben wird der erste wert = 0 oder liege ich da falsch?

Falsch.

Nun pauschal kann man das nicht sagen siehe die Erklärung dazu von Uwe.

gruss

[Uwe Raabe]

Zitat von EWeiss:

Es ist ja eigentlich nicht nötig jedes mal den FPBuffer neu zu erstellen wenn ich es einmal getan habe.

Dann gibt es doch aber auch nur einen Record in der linked List, oder?

BTW, warum überhaupt eine linked List? Eine TList<PassenderRecordTyp> ist doch viel einfacher zu handhaben. Das Ptr Feld im Record wäre dann auch obsolet.

Zitat von EWeiss:

Frage mich nur warum beim doppelklick in dem EurekaLog Dialog auf diese zeile gesprungen wird.
AppendToLinkedList(nReading, sBuffer); // sBuffer soll einen Memoryleak produzieren. das irritiert doch etwas denn sBuffer kann ich dort nicht einfach löschen.

Der geleakte Speicher wird halt genau an der Stelle zugewiesen. Der String wird dann dem Record-Feld zugewiesen, was den Referenzzähler erhöht. Die Freigabe von sBuffer gibt dann aber eben nicht den Stringspeicher frei, da dieser ja noch von dem Record-Feld referenziert wird. Erst wenn der Record mit Dispose freigegeben wird, erfolgt auch die Freigabe des Stringspeichers.

Eurekalog kann aber nur erkennen, wo der Speicher alloziert wurde und das ist eben in dieser Zeile.

[EWeiss]

Sorry Uwe war vorschnell geurteilt
Habe es editiert.

Zitat:

Ist das gleiche Ergebnis wie bei dir.
Ich bin darauf gekommen weil du sagtest

Zitat:

Was mir auffällt ist, daß für jede Zeile im AppendToLinkedList ein New() aufgerufen wird, es aber nur ein einziges Dispose() gibt.

Es ist ja eigentlich nicht nötig jedes mal den FPBuffer neu zu erstellen wenn ich es einmal getan habe.
Doch ist nötig Deshalb nehme ich deine Lösung. Danke noch mal.

Zitat:

BTW, warum überhaupt eine linked List? Eine TList<PassenderRecordTyp> ist doch viel einfacher zu handhaben. Das Ptr Feld im Record wäre dann auch obsolet.

Na ja NonVcl halt wenn nicht unbedingt nötig verwende ich die Win32API.

gruss

[Neutral General]

Zitat von EWeiss:

Zitat:

BTW, warum überhaupt eine linked List? Eine TList<PassenderRecordTyp> ist doch viel einfacher zu handhaben. Das Ptr Feld im Record wäre dann auch obsolet.

Na ja NonVcl halt wenn nicht unbedingt nötig verwende ich die Win32API.

TList<T> ist NonVCL

[EWeiss]

Zitat von Neutral General:

Zitat von EWeiss:

Zitat:

BTW, warum überhaupt eine linked List? Eine TList<PassenderRecordTyp> ist doch viel einfacher zu handhaben. Das Ptr Feld im Record wäre dann auch obsolet.

Na ja NonVcl halt wenn nicht unbedingt nötig verwende ich die Win32API.

TList<T> ist NonVCL

Du hast recht
Habe es nun mal so gemacht.
Und mit Uwes Hilfe wird jetzt alles korrekt frei gegeben.

Danke nochmals.

gruss

[EWeiss]

Hmm.. musste es doch nochmal ändern.
Es funktioniert nur beim ersten mal wird die gleiche Funktion nochmals aufgerufen dann kracht es mit invaliden Pointer.

Delphi-Quellcode:

  { linked List freigeben }
   while LineStart <> nil do begin
     FPBuffer := LineStart;
     LineStart := FPBuffer.Ptr;
     { Bei Dispose kümmert sich der Compiler um das Finalize }
     Dispose(FPBuffer);
   end;
   { keine dangling Pointer hinterlassen }
   FPBuffer := nil;
   FToPBuffer := nil;

so geht's.

Delphi-Quellcode:

  Count := LineStart.Max;
  for i := 0 to Count do
  begin
    FPBuffer := LineStart;
    LineStart := FPBuffer.Ptr;
    Dispose(FPBuffer);
  end;

  Dispose(LineStart);

  FPBuffer := nil;
  FToPBuffer := nil;
  LineStart := nil;

finde den Fehler bei deiner Variante leider nicht.

gruss

[Dennis07]

Warum benutzt du nicht einfach PChar für Strings, die du selber verwalten willst? Oder, meinetwegen, WideString.
Denn "String" ist halt referenzgezählt und wird selber erzeugt und freigegeben. Bei "PChar" hast du auch schon "StrNew" und "StrDispose".

[EWeiss]

[QUOTE=Dennis07;1425881]Warum benutzt du nicht einfach PChar für Strings, die du selber verwalten willst? Oder, meinetwegen, WideString.QUOTE]

Weil ich es nun mal auf string ausgelegt habe und ja die sind auch Unicodefähig zumindest ab Delphi 2009 glaube ich.
Und im Grunde genommen sind Strings in Delphi schon mächtig.
Warum soll ich mich dann mit PChar (PWideChar) rumschlagen wenn es auch so geht.

Sorry aber ich habe keine Lust jetzt meine Library deshalb wieder komplett umzumodeln.
Für Außenstehende ist das einfach zu erfragen warum machst du das nicht so oder so.

Zitat:

Denn "String" ist halt referenzgezählt und wird selber erzeugt und freigegeben

referenzgezählt stimme ich zu.
selbst freigegeben.. nein sonst müsste ich mir nicht die Arbeit machen oder?

gruss