Wer macht den Free?

[Mavarik]

Hallo!

Ich refrakturiere gerade alten Source-Code für einen Kollegen...

Die Frage ist: Wer gibt eine Instance wieder frei... (Gibt's sicher wieder ne tolle Regel)

Beispiel:

Delphi-Quellcode:

Procedure Foo; // Logisch...
var
  LListe : TStringList;
begin
  LListe := TStringList.Create;
  try
    // Whatever
  finally
    LListe.Free; 
  end;
end;

Procedure Bar(Const AListe : TStrings); 
begin
  // Whatever
  
  AListe.Free; // oder nicht?  (wenn kein Const dann klar!)
end;

Function Foo2(Const AParam1,AParam2 : String) : TStrings;
begin
  Result := TStringList.Create;
  Result.AddPair(AParam1,AParam2);
  // Whatever
  // Logischerweise kein Free
end;

Procedure Bar2;
begin
  Bar(Foo2('Value','42'));  
end;

Was ist wenn ich den Source von Bar nicht habe und in der Doc nix steht...

Angenommen Bar gibt die Instance nicht frei, dann ist es ein MemLeak!

Delphi-Quellcode:

Procedure Bar2;
var
  LStrings : TString;
begin
  LStrings := Foos2('Value','42');
  try
    Bar(LStrings);  // Dann hoffen wir mal Bar hat FreeAndNIL verwendet...
                    // Es sei den der Param ist ein Const dann geht FreeAndNIL nicht... 
  finally
    FreeAndNIL(LStrings);
  end;
end;

Besonders wenn man fremden Source liest, sieht man ggf. nicht ob man ein Object frei geben muss oder nicht.

Delphi-Quellcode:

Function Bar3(Const AListe : TStrings) : TStrings;
begin
// Den Source kenne ich nicht...  
end;

Function Bar4;
var
  LListe : TStrings;
begin
  LListe := Bar3(Foo2('Value','42'));
  // Ist LListe meine Instance von Foo2 oder eine neue?
  LListe := Foo2('Value','42');
  LListe := Bar3(LListe); // Hab ich jetzt ein MemLeak?
end;

Wie macht Ihr das?

Mavarik

[Bernhard Geyer]

I.d.R. ist der der Ersteller auch für die Freigabe zuständig.
Hat man Funktionen bei denen das nicht der Fall ist, so ist der Funktions/Methodennamen entsprechend gewählt CreateMySuperDuperInstance(...)
Oder man baut seine Logik auf Interfaces auf. Dann stellt sich einen die Frage gar nicht.

[Mavarik]

Zitat von Bernhard Geyer:

I.d.R. ist der der Ersteller auch für die Freigabe zuständig.
Hat man Funktionen bei denen das nicht der Fall ist, so ist der Funktions/Methodennamen entsprechend gewählt CreateMySuperDuperInstance(...)
Oder man baut seine Logik auf Interfaces auf. Dann stellt sich einen die Frage gar nicht.

Klar mit Interfaces zählen die für einen mit... Bei eigenen Klassen kein Problem, aber was ist, wenn Du eine Procedure hast Du - wie in meinem Beispiel - als Parameter TStrings verlangt... Da kannst Du nicht so einfach IStrings übergeben...

[Stevie]

Gerade bei TStrings hab ich in unserem eigenen Sourcecode oft gesehen, dass hier ein TArray<string> genug gewesen wäre und sich somit die Frage gar nicht mehr stellt.

[Uwe Raabe]

Delphi-Quellcode:

Function Bar3(Const AListe : TStrings) : TStrings;
begin
// Den Source kenne ich nicht...  
end;

Function Bar4;
var
  LListe1 : TStrings;
  LListe2 : TStrings;
begin
  LListe1 := Foo2('Value','42');
  // unter der Annahme, daß Bar3 die Instanz nicht freigibt, was dem const ja widersprechen würde
  LListe2 := Bar3(LListe1);
  if LListe2 <> LListe2 then begin
    LListe2.Free;
  end;
  LListe1.Free;
end;

[Zacherl]

Ohne Quelltext ist sowas immer ein Ratespiel. Ich würde es bei Möglichkeit einfach mal ausprobieren. Eine generelle Faustregel wäre mir nicht bekannt, allerdings halte ich mich auch an das Prinzip, dass der Ersteller für das Freigeben verantwortlich ist. Kann sonst selbst im eigenen Code recht schnell ziemlich unübersichtlich werden.

Eine der Stellen, an der man sich die C++ "Const-ness" wünscht, mit der man nicht nur die Referenz/Pointer als const markieren kann, sondern tatsächlich auch das dahinterliegende Objekt.

[himitsu]

Zitat:

was dem const ja widersprechen würde

Jain.

FreeAndNil würde dem Const wiedersprechen, aber Free per se nicht.
Es wird ja nicht die Variable/Parameter verändert, sondern nur das, worauf sie zeigt.


Also der "Grundsatz" wurde ja schon genannt.
Am Besten gibt immer der etwas frei, der es auch erstellt hat.

Im Falle von solchen Results könnte die Klasse, wo die Get-Methode drin ist, eine GibFrei-Methode anbieten.
Alternativ kommt es auf die Dokumentation an.
Entweder die Get-Methode speichert intern den Zeiger und gibt es später frei, wenn die übergeordnete Klasse auch freigegeben wird, bzw. beim nächsten Aufruf der Get-Methode.
Oder man definiert es so, dass der "Caller" in soeinem Fall das freigeben muß. (ich würde das auch präferieren)

[Mavarik]

Zitat von Stevie:

Gerade bei TStrings hab ich in unserem eigenen Sourcecode oft gesehen, dass hier ein TArray<string> genug gewesen wäre und sich somit die Frage gar nicht mehr stellt.

ja so mache ich es auch...

Zitat von Zacherl:

Eine der Stellen, an der man sich die C++ "Const-ness" wünscht, mit der man nicht nur die Referenz/Pointer als const markieren kann, sondern tatsächlich auch das dahinterliegende Objekt.

Ja - der Kollege hat im ganzen Source FreeAndNIL genommen und wäre er dabei geblieben - alles gut - aber da viele der Proceduren mit CONST sind hat er in diesen Fällen

AListe.Free genommen... (Manchmal)

Ich muss mir also jeder Procedure einzeln ansehen und das in alle tiefen, ob jemand aufräumt... ätzend...

Da lobe ich mir doch die Interfaces...

Mavarik

[striderx]

"Ich refrakturiere gerade alten Source-Code für einen Kollegen..."

Das ist aber nicht sehr nett von dir ...

[Mavarik]

Zitat von striderx:

"Ich refrakturiere gerade alten Source-Code für einen Kollegen..."

Das ist aber nicht sehr nett von dir ...

Ja genau - ich breche den Code in Teile...