TStringList freigeben?

[Tyrolean]

Zitat von Mysterio08:

Hallo,

ich habe eine Funktion erstellt, bei der eine TStringList den Rückgabewert definiert. Auf der Suche danach, wie ich diese TStringList freigebe, habe ich in einem Buch gesehen, dass man das weglassen kann. Aber ist das auch wirklich guter Programmierstil?
Wenn nicht: Wie muss ich dann Result freigeben, damit nicht eine leere TStringList zurückgegeben wird?

mfg.

*Wie* man eine Stringlist freigibt ist klar. Stringlist.Free. die Frage ist eher wann

Delphi-Quellcode:

var
  sl : TStringlist;
begin
  sl := Callfunction;
  // mit sl viel oder wenig tun
  sl.Free;
end;

[Deep-Sea]

@Tyrolean:
Try-finally nicht vergessen

[Tyrolean]

Zitat von Deep-Sea:

@Tyrolean:
Try-finally nicht vergessen

eh klar

[Luckie]

also ich bin der Meinung, dass man Objekte auch da wieder freizugeben sollte, wo man sie erzeugt. Ansonsten wird es ziemlich unübersichtlich und man ist am Suchen, wo das erzeugte Objekt wieder freigegebene wird:

Delphi-Quellcode:

procedure FooBar(Strings: TStrings);
begin
  Strings.Add('jsbvjdasbjÄ');
  Strings.Add('iuerwtrei');
end;

Und der Aufruf:

Delphi-Quellcode:

var
  Strings: TStringList;
begin
  Strings := TStringList.Create;
  try
    Foobar(Strings);
    // Mach was mit Strings
  finally
    Strings.Free;
  end;

Damit ist auch der Aufrufer der Funktion für das Freigeben verantwortlich und man hat alles zusammen und man muss nicht wild umher scrollen, um den Ort zu finden, wo das Objekt wieder freigegeben wird.

[DeddyH]

@Luckie: Hatten wir das nicht schon 2 mal gesagt?
@Mysterio: hast Du denn auch eine Exception provoziert?

[Mysterio08]

Zitat von DeddyH:

@Mysterio: hast Du denn auch eine Exception provoziert?

Nein, habe ich nicht. Das heißt dann aber auch: Wenn keine Exception (bewusst) ausgelöst wird, wird das Objekt nicht freigegeben! Irgendwie ein wenig "verkrampft" dieses Prinzip, wie es mir gerade erscheint...

[DeddyH]

Du willst das Objekt ja zurückgeben, daher darf es natürlich nicht innerhalb der Funktion freigegeben werden (wir machen das ja nur im Fehlerfall und geben über die Exception Rückmeldung, dass etwas schief gegangen ist). Und wie Du selbst bemerkst, ist diese Vorgehensweise daher alles andere als optimal.

[Deep-Sea]

Delphi-Quellcode:

function UnsichereMethode: TStringList;
begin
  Result := TStringlist.Create;
  Result.Add('Eins');
  raise Exception.Create('Ein Test.');
  Result.Add('Zwei');
end;

function SichereMethode: TStringList;
begin
  Result := TStringlist.Create;
  try
    Result.Add('Eins');
    raise Exception.Create('Ein Test.');
    Result.Add('Zwei');
  except
    Result.Free;
    raise;
  end;
end;

procedure TueEtwas;
var
  LList: TStringList;
begin
  LList := SichereMethode;
  try
    // Tue etwas mit LList
  finally
    LList.Free;
  end;
end;

Würdest du nun in TueEtwas anstatt SichereMethode die Funktion UnsichereMethode aufrufen, würde ein Speicherleck entstehen, da du das LList.Free in TueEtwas nie erreichst. Darum ist in SichereMethode der Try-except-Block, um im Fehlerfall die Liste freizugeben und somit ein Speicherleck zu verhindern.

[Luckie]

Zitat von DeddyH:

@Luckie: Hatten wir das nicht schon 2 mal gesagt?

Ja, hattet ihr. Aber ich hatte im Thread noch keinen schönen Beispielcode gesehen, deswegen noch mal von mir.

[DeddyH]

Zitat von Luckie:

Aber ich hatte im Thread noch keinen schönen Beispielcode gesehen, deswegen noch mal von mir.

Die möglichen Spielarten standen doch bereits in #2, aber egal.