Speicherbereinigung von Strings

[3_of_8]

Morgen.

Ich habe ein kleines Problem.

Ich speichere einen Pointer auf einen String in einer Datenstruktur. Da stellt sich natürlich die Frage: Wann gibt der Speichermanager den String frei? Kann es sein, dass von dem String nichts mehr übrig ist, wenn ich den Pointer wieder aus der Struktur hole? Muss ich den String in eine Wrapper-Klasse verpacken?

[alzaimar]

Ohne genau probiert zu haben, denke ich, das der String freigegeben wird, wenn der Kontext verlassen wird. Seine Adresse ist dann imho nicht mehr gültig. Zeig doch mal Code, würde mich nämlich auch interessieren.

[3_of_8]

Ich bin noch in der Planungsphase. Im Prinzip wäre das aber so, dass ich sowas bräuchte wie eine HashMap<String, String> in Java, also eine String zu String-Map. Am einfachsten wäre es gewesen, wenn ich meine bereits vorhandene HashMap<String, Pointer>-Klasse nehmen würde, und einfach einen Pointer auf den String legen würde. Ich probiers mal aus.

[Dax]

Ein String wird dann freigegeben, wenn keine Referenz mehr auf ihn existiert. Damit hat alzaimar für die Mehrzahl der Fälle (globale Variablen, Felder und lokale Variablen, die an höhere Gültigkeitsbereiche durchgereicht werden) recht. Den String musst du nicht unbedingt in eine Klasse packen, ein Record tut es genauso - allerdings ist der String selbst intern auch eine Art Klasse, also kannst du auch einfach nach Pointer und zurück casten ;)

[3_of_8]

Ja, kann ich - aber der Speichermanager macht Hackfleisch daraus, hab es grad getestet. Mit nem record hab ichs jetzt nicht probiert, aber der String wurde offenbar freigegeben, das letzte Zeichen war unbrauchbar, nachdem ich den Pointer dereferenziert habe. Jetzt habe ich ihn in eine Klasse gewrappt und das ganze funktioniert. Danke trotzdem.

[Hawkeye219]

Hallo,

ein einfacher TypeCast auf Pointer dürfte nicht ausreichen, damit unterläuft man die Referenzzählung. Zum Speichern und späteren Auslesen der Strings über Pointer kann man wie folgt vorgehen:

Delphi-Quellcode:

var
  List : TList;
  i : Integer;
  ps : PString;
begin
  List := TList.Create;

  for i := 0 to 9 do
    begin
      New (ps);
      ps^ := IntToStr(i);
      List.Add(ps);
    end;

  {...}

  for i := 0 to 9 do
    begin
      ps := PString(List[i]);
      ShowMessage (ps^);
    end;

  for i := 0 to 9 do
    Dispose (PString(List[i]));

  List.Free;
end;

Das TList-Objekt ist natürlich nur ein Platzhalter für die tatsächliche Datenstruktur.

Gruß Hawkeye

[3_of_8]

Das wollte ich so ungefähr wissen. Ich finde aber fast, dass eine Wrapper-Klasse eleganter ist.

[sirius]

Oder du zählst einfach den Referenzzähler eins hoch. Der liegt 8 Byte vor der Stringaddresse. (und hinterher natürlich wieder eins runter :mrgreen:

[alzaimar]

Geht das nur mit:

Delphi-Quellcode:

InterlockedIncrement(PInteger (Integer(MyString)-8)^);

oder gibt es da eine elegantere Methode, wie z.B. eine Art _AddRef?

[edit] Adresse des Strings berichtigt. @MyString ist die Adresse des Pointers, nicht der Speicherbereich des Strings![/edit]

[sirius]

An sowas dachte ich. Habe ich bisher auch nicht anders gemacht. Aber warum Lock Inc?

[SirThornberry]

:shock: Mach das bloß nicht. Niemand garantiert dir das es in der nächsten Delphiversion noch genau so ist und dann kannst du dein Projekt weg werfen.
Alle Variablen die du definierst werden innerhalb eines gewissen Bereiches desfiniert (lokal, global, membervariable). Sobald diese Bereiche verlassen werden verlieren auch die Variablen ihre Gültigkeit.
Wenn du also bei verlassen der Bereiche die Werte hinter den Variablen nicht verlieren willst, musst du wie bereits gezeigt den Speicher explizit anfordern. Nur explizit angeforderter Speicher wird auch erst frei gegeben wenn er explizit freigegeben wird. Wenn Speicher automatisch reserviert wird durch declaration in einem Gültigkeitsbereich wird er auch automatisch frei gegeben.

Mach dir am besten eine schöne Klasse oder ein dynamisches Array wenn du mit Klassen nicht so fit bist. Irgendwo im Speicher rum schreiben und darauf verlassen das sich die Struktur nie ändert ist der falsche Ansatz.

[sirius]

Ergänzung: Du musst noch aufpassen, dass der Referenzzähler <> -1 ist, dann nicht verändern.

oder so

Delphi-Quellcode:

asm
  mov eax,your_ansi_string
  call system.@lstraddref
end;

@sir: Solange man das kann, ist es mit Abstand der bessere Weg. Abgesehen davon bin ich bei Strings mit Kombatibilitätsaussagen sowieso etwas vorsichtig. Mal sehen was noch alles läuft, wenn Delphi mal komplett auf Unicode umgestiegen ist.

[alzaimar]

Ergo: eine Wrapperklasse/Record basteln und den String kopieren (was einem 'Add Reference') gleichkommt. Alternativ den String direkt in die Hashmap schreiben

[Apollonius]

Zitat:

Zitat von alzaimar

Delphi-Quellcode:

InterlockedIncrement(PInteger (Integer(@MyString)-8)^);

Ich dachte, ein Ansistring ist an sich schon ein Pointer (sagt auch die Hilfe). Warum dann noch der Adressoperator?

[alzaimar]

Ist für mich verständlicher. Außerdem ist Integer(MyString) <> Integer(@MyString)

[Apollonius]

War mir durchaus klar. Aber was ist richtig? Die Adresse eines Pointers? Ist das hier sinnvoll?

[alzaimar]

Aus der Systems.pas

Delphi-Quellcode:

Type
  PStrRec = ^StrRec;
  StrRec = packed record
    refCnt: Longint;
    length: Longint;
  end;

const
  skew = sizeof(StrRec);
  rOff = sizeof(StrRec); { refCnt offset }
  overHead = sizeof(StrRec) + 1;

procedure _LStrClr(var S);
var
  P: PStrRec;
begin
  if Pointer(S) <> nil then
  begin
    P := Pointer(Integer(S) - Sizeof(StrRec));
...

Also... Deine Version.. hö hö. Werd ich gleich mal berichtigen.

[3_of_8]

@alzaimar: Einen record zu nehmen, bringt eigentlich nichts, denn dann hast du das gleiche Problem mit dem record, weil der schließlich auch freigegeben wird, wenn du nicht seinen Referenzzähler erhöhst.

[alzaimar]

Meine Hashmap speichert immer Pointer, daher ein Record bzw. ein Zeiger darauf. Aber ich glaub ich erweitere meine Unit um eine Klasse, die String/String und Cardinal/String Tupel speichert.

[3_of_8]

Und wie verhinderst du, dass der record freigegeben wird? Das ist ja dann im Prinzip das gleiche Problem wie bei dem String.

[DGL-luke]

öhm...

Delphi-Quellcode:

PStringContainer = ^TStringContainer;
TStringContainer = record
  s: string;
end;

//string "sichern"
New(MyPStringContainer);
MyPStringContainer.s := 'bla';
//und dann record in ne liste packen.

//string freigeben
Dispose(MyPStringContainer);

soltle das nicht reichen?

[3_of_8]

Ja, aber dann könnte man sich den Record schenken und gleich nen String nehmen.

[alzaimar]

Meine Hashmap speichert Pointer, und da wollte ich DGL-Luke's Version nehmen.

[Tyrael Y.]

Delphi-Quellcode:

type
  PRecordType = ^TRecordType; 
  TRecordType = record
    Name: string;
    Bla: string
  end; 

procedure Test();
var LRec: PRecordType;
begin
  New(LRec);
  try
    LRec.Name := 'Name';
    LRec.Bla := 'BlaBla';
    
    MachWas(LRec);
  finally
    LRec.Name := '';
    LRec.Bla := '';
    Dispose(LRec);
  end; 
end;

...probiert es aus

[alzaimar]

Zitat:

Zitat von Tyrael Y.

...probiert es aus

Wozu sollte man die Strings zum Schluss auf '' setzen? Und wozu sollte man das ausprobieren?

[Tyrael Y.]

Hm, sry ist wohl doch nicht so wie ich es mir gedacht habe...hab es jetzt selbst nochmal gestestet und in diesem Fall entsteht kein Leak.

Wieso ich auf diese Idee gekommen bin....beim VirtualStringTree erzeugen Strings in einem PNodeData einen Memory Leak, wenn sie nicht im OnFreeNode auf leer gesetzt werden.
Meine Annahme war, weil ich sehr viel mit dem VST arbeite, daß es bei Strings in Records immer so ist. Ein Test zeigte mir das Gegenteil. Es entstehen keine Leaks. Beim VST liegt es wohl daran, daß der Record untypisiert ist.

Gruß T.

[himitsu]

Zitat:

Zitat von Tyrael Y.

Beim VST liegt es wohl daran, daß der Record untypisiert ist.

genau so ist es, denn woher sollte sollte VST denn wissen was du in dem Record speicherst?
VST bekommt ja vom Inhalt und dessen Typen nichts mit ... du kastest den Typ ja auch erst außerhalb des VST.

aber das ist überall so, wo der Typ nicht direkt angegeben ist und wo dieses dann nicht explizit bei der Freigabe beachtet wird.