Record zurücksetzen (löschen)

[FAlter]

Hi,

Zitat:

Zitat von Hansa

Zitat:

Zitat von Christian Seehase

Ausserdem sind Huge-Strings auch die Standardeinstellung.
Hast Du es bei Dir umgestellt? ;-)

Ne, nichts umgestellt. Warum auch ? Die Screenshots wurden produziert mit Projektoptionen-Checkbox "Huge-Strings" angehakt. Mache ich aus dem string [10] nur string, dann gehts genauso. @DeddyH

Vom Effekt her scheint es gleich zu sein, allerdings wird der Speicher nicht freigegeben, den die Strings belegen, sondern nur der Zeiger auf nil gesetzt (was bei Delphi Leerstring bedeutet).

Mfg
FAlter

[Neutral General]

Zitat:

Zitat von Hansa

Ne, nichts umgestellt. Warum auch ? Die Screenshots wurden produziert mit Projektoptionen-Checkbox "Huge-Strings" angehakt. Mache ich aus dem string [10] nur string, dann gehts genauso. @DeddyH

Ich würde mal sagen: Damit wäre

Zitat:

Zitat von Neutral General

Mir scheint, als hätte er nicht verstanden, worum es hier in dieser Diskussion geht. :roll:

bewiesen :P

Natürlich wird der String auch ohne Finalize zu einem Leerstring. Allerdings hinterlässt du ein MemoryLeak.

Du machst quasi folgendes:

Delphi-Quellcode:

var pc: PChar;
begin
  GetMem(pc,6);
  // mit PChar arbeiten
  pc := nil; // = FillChar(String,SizeOf(String),0);
end;

Ich denke du siehst, dass obiger Code ein MemoryLeak verursacht. Richtig wäre es so:

Delphi-Quellcode:

var pc: PChar;
begin
  GetMem(pc,6);
  // mit PChar arbeiten
  FreeMem(pc); // Finalize(RecordmitString);
  pc := nil; // = FillChar(RecordmitString,SizeOf(TRecordmitString),0);
end;

Ich hoffe, du hast jetzt verstanden worum es geht. Im Endeffekt ist pc immer nil. Das Ergebnis ist scheinbar das Gleiche.

[Luckie]

Hm. :gruebel:

also Records sind ja sowieso nicht mehr ganz OOP konform. Gerad ein so einen Fall bieten sich klassen an, da Klassen Daten und Methoden die Daten zu manipulieren kapseln. Da würde ich dann eine Methode Init schreiben, die die Attribute auf einen definierten Wert setzt.

Was passiert eigentlich mit String Attributen, wenn man des Objekt auf nil setzt?

[Neutral General]

Zitat:

Zitat von Luckie

Was passiert eigentlich mit String Attributen, wenn man des Objekt auf nil setzt?

Der String liegt weiterhin im Speicher rum und wird nicht freigegeben. (MemoryLeak)

[Luckie]

Das ist ja Müll.

[Neutral General]

Was hast du denn erwartet/gehofft? :gruebel:

[Luckie]

Dass der MemoryManager erkennt, dass es sich um Strings handelt und den Speicher entsprechend freigibt.

[SubData]

So... Und ich hab da auch mal was nettes:

Folgendes Konstrukt:

Delphi-Quellcode:

type
  TThreadVars = record
    sServerHost : String;
    sRemoteIP   : String;
    sPHPSession : String;
    sVar1       : String;
    sVar2       : String;
    sVar3       : String;
    sVar4       : String;
    sVar5       : String;
    dVar1       : TDateTime;
    iVar1       : Int64;
    (* --- Request Infos --- *)
    pThread     : ^TIdContext;
    pRequest    : ^TIdHTTPRequestInfo;
    pResponse   : ^TIdHTTPResponseInfo;    
  end;

threadvar
  tv              : TThreadVars;

Am Anfang des Threads werden alle Felder gefüllt bzw. irgendwann im laufenden Thread.

Am Ende des Threads wird folgendes aufgerufen:

Delphi-Quellcode:

    Finalize(tv);
    FillChar(tv, SizeOf(tv), 0);

Und was passiert?

Richtig, ich hab ein Memory Leak.
Allerdings nur in den ersten 3 String Variablen.
Wenn ich diese per Hand auf zurücksetze ( var := ''; ) dann ist das Memory Leak weg...

[jfheins]

Zitat:

Zitat von Luckie

Was passiert eigentlich mit String Attributen, wenn man des Objekt auf nil setzt?

Zitat:

Speicherleck ....... Ist ja Müll ...... Was hast du denn erwartet?

Zitat:

Zitat von Luckie

Dass der MemoryManager erkennt, dass es sich um Strings handelt und den Speicher entsprechend freigibt.

Wir sind heir doch nicht in .NET (oder Java) ;)

Da reicht ein nil setzen volkomen aus, und der Memorymanager(/GC) kümmert sich um den Rest ;)

Zum Thema: Eine Klasse wäre natürlich praktischer. Dann kannst du auch direkt die Klasse Thread-Safe implementieren und alles sollte klappen :stupid:

[Guido Eisenbeis]

@All

OK, ... ich ... schreibe ... jetzt ... mal ... sehr ... langsam und lasse mir Zeit, bevor ich diese Posting losschicke. Ich will mich eigentlich schon die ganze Zeit bedanken für die rege Beteiligung und die wirklich guten Infos. Aber jedes Mal wenn ich ansetze, um dies zu schreiben kommen in der Zwischenzeit wieder neue Beiträge. ;-) Ihr seid richtig flott! Ich bin erfreut und beeindruckt, was hier eine rege Diskussion entstanden ist.

Ich habe an einem bestimmten Punkt gedacht, dass die FillChar-Möglichkeit eine Lösung für das Thema meines Threads ist. Dann kamen neue Infos und ich begann über die Speicherlecks zu grübeln. Dann war wieder alles klar, und nach einigen weiteren Post gings von vorne los. Ich träume schon von Speicherlecks! :cyclops:

Nun habe ich mich entschieden, dass die FillChar-Lösung die richtige für mein Problem ist und werde sie verwenden. Ich habe auch ein kleines Demo dazu geschrieben. Das fasst zwar im Prinzip nur die hier geposteten Infos zusammen, aber wenn Interesse besteht, werde ich das Demo gerne hier posten.

Ansonsten freue ich mich auch weiterhin über Infos, die zu diesem Thema beitragen! :P

Guido.