TStringList als Result einer Funktion

[Captnemo]

Zitat von himitsu:

PS: Auch wenn du intern eine TStringList erzeugst ... Es macht sich dennoch oft besser, wenn das Result-Typ ein TStrings ist.

Kannst du mir auch sagen warum das sich besser macht?

[Dejan Vu]

Wenn man interfaces benutzt, sollte man nur interfaces nehmen und keinen Mischmasch. Denn wie erkennt man, wo man etwas manuell freigeben muss und wo nicht? Also nichts gegen die Lösung, aber als isolierte Lösung hier würde ich das nicht machen.

Die eigentliche Frage ist ja (wenn man Sherlock's law beachtet) Wie erkennt man (wie im Beispiel des TE), das die Funktion eine Liste liefert, die man freigeben muss? Wer ist hier wirklich der Ersteller?

Ich würde das so lösen, das die Funktion eine Methode ist, die in eine ihr übergebene Liste die Tiernamen anhängt, und eben keine neue Instanz liefert.

Delphi-Quellcode:

Procedure FillTiere (aDestination : TStringList);
begin
  aDestination.Add('Hund');
  aDestination.Add('Katze');
  aDestination.Add('Maus');
end;

Dann kann man sie so aufrufen: FillTiere(ListBox.Items) oder so:

Delphi-Quellcode:

  tmp := TStringList.Create;
  Try
    FillTiere (tmp);
    ListBox.Items.Assign(tmp);
  finally
    tmp.Free
  end

Somit ist klar, wer Ersteller ist.

[Perlsau]

Delphi-Quellcode:

function GetTiere: String;
Var
  Liste: TStrings;
begin
  Liste:=TStringList.create;
  Try
    Liste.Add('Hund');
    Liste.Add('Katze');
    Liste.Add('Maus');
    Result := Liste.Text;
  Finally
    Liste.Free;
  End;
end;

// Aufruf:
Listbox1.Items.Text := GetTiere;

[DeddyH]

Wie schon eingangs erwähnt:

Delphi-Quellcode:

procedure GetTiere(const Dest: TStrings);
begin
  Assert(Assigned(Dest));
  Dest.BeginUpdate;
  try
    Dest.Clear;
    Dest.Add('Hund');
    Dest.Add('Katze');
    Dest.Add('Maus');
  finally
    Dest.EndUpdate;
  end;
end;

GetTiere(ListBox1.Items);

[p80286]

Zitat von DeddyH:

Wie schon eingangs erwähnt:
procedure GetTiere(const Dest: TStrings);

Hält Dir zusätzlich die Möglichkeit offen mit Dest.Clear; die übergebene Liste zu löschen oder aber die Daten unten oder sonstwo anzuhängen. Miteiner Funktion bist Du nicht so flexibel.

Gruß
K-H

P.S.
Irgendwann vergisst jeder einmal die Liste wieder frei zu geben.

[Dejan Vu]

Es wurde auch schon 1000,3x gesagt: Funktionen sollten in Delphi eben keine Instanzen erzeugen und liefern, außer es ist auch vom Namen her klar, das da was erzeugt wird. Aber trotzdem würde ich das nie machen. Einfach weil.

[mkinzler]

Kompromiss:

Delphi-Quellcode:

function CreateList( list: TStrings): TStrings;
begin
if not Assigned( list) then
   list := TStringList.Create;
   list.Add( 'a');
   list.Add( 'b');
   list.Add( 'b');
   Result := list;
end;


procedure TForm1.Button1Click(Sender: TObject);
var
  sl: TStrings;
begin
  try
    sl := CreateList( TStringList.Create);
    Memo1.Lines.Assign( sl);
  finally
    sl.Free;
  end;
end;

[sx2008]

Ich würde ganz klar den Vorschlag von DeddyH (Beitrag #16) bevorzugen wenn auch mit kleinen Änderungen.
Das Clear wird weggelassen und der Name beginnt mit Appendxxx.

Delphi-Quellcode:

procedure AppendTiere(const Dest: TStrings);
begin
  Assert(Assigned(Dest));
  Dest.BeginUpdate;
  try
    Dest.Add('Hund');
    Dest.Add('Katze');
    Dest.Add('Maus');
  finally
    Dest.EndUpdate;
  end;
end;

Je nach Anwendungsfall kann man das Clear auch dazunehmen; nur dann beginnt die Prozedure mit Fillxxx.
Wenn ich weiss, dass die Prozedure nicht mehr als 100 Einträge erzeugen wird, dann lasse ich auch BeginUpdate und EndUpdate weg.

[Sir Rufo]

Nur so aus Spass (dann sind doch alle glücklich)

Delphi-Quellcode:

procedure FillWithAnimals( const Dest: TStrings; Append : Boolean = False );
begin
  Assert(Assigned(Dest));
  Dest.BeginUpdate;
  try
    if not Append then
      Dest.Clear;
    Dest.Add('Hund');
    Dest.Add('Katze');
    Dest.Add('Maus');
  finally
    Dest.EndUpdate;
  end;
end;

[himitsu]

Zitat von Sir Rufo:

Nur so aus Spass (dann sind doch alle glücklich)

Ähhhhhhhhhhhhhhhhhhhhhhhhhhh....

Ne


Append wird ja immer gemacht, aber das Clear wird gesteuert.

Delphi-Quellcode:

procedure FillWithAnimals(Dest: TStrings; Clear: Boolean=False); 
// oder doch AppendAnimals (ohne Denglisch), ist nun auch egal, wobei es ja dennoch immer Append macht

Ja, Const ist schon richtig, da die Referenz wirklich nicht verändert wird, aber da man was in der Klasse verändert (hinzufügt), finde ich es imho etwas "verwirrend".
Wobei var natückich "logisch" gesehn eindeutiger wäre, aber in Bezug auf den Zeiger ja vollkommen falsch ... dann doch lieber ohne.

Mir würde es ja gefallen, wenn man für Klassen/Zeigertypen dennoch ein IN und OUT angeben könnte, als Info für den Entwickler. (wobei man das ja im HelpInsigt/DokuInsigt machen könnte, wenn man es da einführen täte)

Und hier ist das Problem mit der typisierung besonders groß.
> mit VAR könnte man nur genau diesen Typen, als übergebene Variable verwenden und was drin ist, ist egal
> bei TStringList kann man nur TStringList und Nachfahren reingeben, obwohl intern nur Methoden des TStrings verwendet werden
> mit TStrings wäre auch ein Memo.Lines möglich