Function, Result als stringlist?

[Pseudemys Nelsoni]

hallo,

ich möchte eine stringlist(innerhalb der function) haben, aber wie geb ich dann das ergebnis an meine procedur? schliesslich muss ich am ende ja die stringlist wieder free'en. ich hatte es so(weiss nichtmal ob es überhaupt so geht):

Delphi-Quellcode:

function bla(s: string; c: char): TStringList;
begin
  Result := TStringList.Create;
  while Pos(c, s) > 0 do
  begin
    result.Add(Copy(s, 1, Pos(c, s)));
    Delete(s, 1, Pos(c, s));
  end;
  result.Free;
end;

ich kriege immer einen zugriffsfehler, ich denke mal weil die stringlist bereits nichtmehr existiert.

[Tom]

Ja. Free ist Free.

[Luckie]

Tut sie auch nicht.

Delphi-Quellcode:

procedure Foo(s: String; c: Char; var sl: TStringList);
begin
  ...;
end;

var
  sl: TStringList;
begin
  sl := TStringList.Create;
  try
    Foo('Hello', 'c', sl);
  finally
    FreeAndNil(sl);
  end;

Mal so aus dem Kopf.

[Pseudemys Nelsoni]

echt :?:

wie benutz ich eine stringlist als result :?: :!:
ist es möglich die function selbst als stringlist zu benutzen? oder muss ich eine in meiner procedure mitgeben? O_o

[Pseudemys Nelsoni]

danke luckie, mal versuchen ^^

[Wormid]

Lass das Result.Free mal weg, dann müsste es gehen.
Du musst aber natürlich später die Variable Free'n, die du mit der Funktion gefüllt hast.

Delphi-Quellcode:

var SL: TStringList;
begin
  SL := bla('blubb', #13);
  // ... Mach was mit SL
  SL.Free;
end;

Gruß

Wormid

[Pseudemys Nelsoni]

funzt einwandfrei, danke ;)

nochmal ne frage, wieso FreeAndNil statt Free? bzw was ist der unterschied?

[Luckie]

Free gibt nur den Speicher wieder frei. Der Zeiger auf das Objekt bleibt bestehen. Testet man jetzt den zeiger mit Assigned, um zu kucken, ob das Objekt noch existiert, bekommt man True zurück, obwohl das nicht stimmen muss. Man sollte bei der Verwendung von Free auch noch den Zeiger auf Nil setzen. Dies spart man sich, wenn man FreeAndNil nimmt.

[himitsu]

Oder so:

Delphi-Quellcode:

function bla(s: string; c: char): TStringList;
begin
  Result := TStringList.Create;
  while Pos(c, s) > 0 do begin
    result.Add(Copy(s, 1, Pos(c, s)));
    Delete(s, 1, Pos(c, s));
  end;
end;


var SL: TStringList; 
begin
  {sollte in SL vorher schon was sein => SL.Free}
  SL := bla('4t54gfd', 'f');
  SL.FreeAndNil;
end;

[Luckie]

FreeAndNil ist eine Prozedur, keine Methode von einer Klasse.

Davon mal abgesehen finde ich meine Lösung besser. Man verliert nicht den Überblick ü+ber die Instanzen der Klasse und muss nicht überlegen, wo was wie freigegeben werden muss / kann. Aber das ist Geschmackssache. :wink:

[Tom]

Zitat:

Zitat von himitsu

Delphi-Quellcode:

function bla(s: string; c: char): TStringList;
begin
  {nur wenn StringList noch nicht erstellt} Result := TStringList.Create;

Wie sollte die StringListe vorher erstellt werden können bei diesem Beispiel?

[Pseudemys Nelsoni]

danke für die gute beschreibung =). nochmal die frage, wieso gibt es überhaupt "free" wenn "freeandnil" "besser" ist?

[Tom]

Wofür mußt Du einen Zeiger auf NIL setzen, wenn dieser garantiert nicht mehr gebraucht wird (z.B. Verwendung von lokalen Variablen)?

[Luckie]

Sicher ist sicher.

[OLLI_T]

Hallo Silent!

Free ist eine Klassenmethode, die überprüft ob das Objekt gültig ist und dann den Destructor aufruft, damit der alloktierte Speicher wieder freigegeben wird. Die Funktion FreeAndNil ruft auch Free auf!

FreeAndNil kannst Du demnach auch so abbilden:

Delphi-Quellcode:

SL.Free; SL:=NIL

Wie Tom schon angemerkt hat, ist das bei lokalen Variablen nicht nötig. Da reicht es Free aufzurufen.

Gruss

OLLI

[choose]

Zitat:

Zitat von Luckie

Delphi-Quellcode:

procedure Foo(s: String; c: Char; var sl: TStringList);

Hallo Luckie, hallo silent,

bei diesem Aufruf könnte der unbedachte Entwickler von Foo, der lediglich die Schnittstelle bekommt, folgendes Schreiben:

Delphi-Quellcode:

procedure Foo(s: string; c: Char; var sl: TStringList);
begin
  sl:= TStringList.Create;
  //...
end;

Schließlich geht er davon aus, dass in sl ein Ergebnis zu stehen hat. In diesem Fall (da CallByReference) würde alles "fehlerfrei" funktionieren, allerdings die ürsprüngliche Referenz (erzeugt beim Klienten) verloren sein!

Es bietet sich an, die Schlüsselworte const und out zu verwenden, um deutlich zu machen, ob eine Variable oder ein Exemplar unverändert bleibt (auch wenn das nicht von Delphi überprüft wird) oder ob ein Parameter lediglich als Ergebnis dient und, im Falle eines Objekts, innerhalb der Routine erzeugt werden soll.
Der verbleibende Fall, weder const nocht out, bedeutet dann konstequenterweise, dass ein (wahrscheinlich) initialisiertes Objekt übergeben und verändert werden kann, jedoch nicht innerhalb der Routine erzeugt wird...

Delphi-Quellcode:

//:Creates and fills a new object
procedure CreateNewInstance(out AnInstance: TMyClass);
//:Uses an object but doesnt modify it
procedure ReadFromInstance(const AnInstance: TMyClass);
//:Uses and may modify an object
procedure ReadFromAndWriteToInstance(AnInstance: TMyClass);

Diese Konvention hat sich in der Praxis gut bewährt und reichte zusammen mit sprechenden Bezeichnungen oft als Schnittstellenbezeichnungen für einfache Routinen aus

Zitat:

Zitat von Tom

Wofür mußt Du einen Zeiger auf NIL setzen, wenn dieser garantiert nicht mehr gebraucht wird (z.B. Verwendung von lokalen Variablen)?

@TOM: Auch wenn man selbst eine Variable nicht länger braucht, kann ein anderer das nicht ahnen... Hat er die Aufgabe, Deinen Code zu erweitern und findet er die passende Variable, könnte es sein, dass er die Freigabe übersehen hat. Ein neue eingeführter Code der Art

Delphi-Quellcode:

//signature and intent of new code
Assert(Assigned(sl));
if sl.Count>0 then
  FooBar(sl[0]);

würde ihn sofort auf seinen Fehler aufmerksam machen.

[sakura]

Spät, aber ich möchte kurz auf Luckies Lösung einsteigen:

Code:

procedure Foo(s: String; c: Char; [color=#1b00ff]var[/color] sl: TStringList);
begin
  ...;
end;

Dieses var stört mich ein wenig. Var impliziert eigentlich, daß die Prozedur den Zeiger ändern könnte. Z.B. könnte, wenn SL als nil übergeben wird, diese erstellt werden, oder ähnliches. Sollte dieses in der Prozedur nicht geschehen, dann sollte das var auch weggelassen werden. Der Inhalt der StringListe kann ja weiterhin manipuliert werden ;-)

...:cat:...

[Tom]

Zitat:

Zitat von choose

@TOM: Auch wenn man selbst eine Variable nicht länger braucht, kann ein anderer das nicht ahnen...

Häh? Bei lokalen Variablen kann das ein anderer nicht ahnen? Prozeduren/Funktionen/Methoden sollten doch eh auf eine Bildschirmseite passen ...

[Pseudemys Nelsoni]

danke ;)

[OLLI_T]

Hallo Sakura!

Zitat:

Dieses var stört mich ein wenig

Das Var kann aber auch recht nüttzlich sein. So kann die Funktion das Objekt bei Bedarf initialisieren.

Delphi-Quellcode:

procedure Foo(s: String; c: Char; var sl: TStringList); 
begin 
  If SL = NIL Then SL:=TStringList.Create;
  ...
end;

Mahlzeit

[sakura]

Zu Ende lesen ;-)

Zitat:

Zitat von OLLI_T

Das Var kann aber auch recht nüttzlich sein. So kann die Funktion das Objekt bei Bedarf initialisieren.

Ich zitiere mich mal selbst:

Zitat:

Zitat von sakura

Z.B. könnte, wenn SL als nil übergeben wird, diese erstellt werden, oder ähnliches. Sollte dieses in der Prozedur nicht geschehen, dann sollte das var auch weggelassen werden.

...:cat:...

[choose]

Hallo Tom,

niemand ist (zum Glück) perfekt, versteht immer hunderprozentig jeden Code, hat immer die nötige Sorgfalt und das erforderliche Maß an Schlaf genossen... Kombiniert mit Termindruck ist es manchmal hilfreich, Regeln zu haben, deren Einhaltung nichts oder wenig kostet ("FN"+<Strg>+<J>), den zu wartenen Code "vertrauter" machen und die Qualität des Ergebnisses verbessern können.

[Tom]

Mal etwas Source: Lokal schreibt man es ja so:

Delphi-Quellcode:

... := ....Create;
try
  // mach was
finally
  ...free;
end;

Ich denke nicht, dass jemand auf die Idee kommen kann ausserhalb von Try/Finally auf das Object zuzugreifen.

[Luckie]

Weißt du wer deinen Code nachher in der Firma in die Finger bekommt? Und wenn zwischen dem Try und finally zwei Bildschirmseiten Code liegen, muss man das nicht unbedingt merken.

[Tom]

Zitat:

Zitat von Luckie

Weißt du wer deinen Code nachher in der Firma in die Finger bekommt?

Unwahrscheinlich ...

Zitat:

Und wenn zwischen dem Try und finally zwei Bildschirmseiten Code liegen, muss man das nicht unbedingt merken.

Wer das nicht merkt, macht auch keine Sicherheitsabfrage auf Nil.

[Luckie]

Es soll aber leute geben, die in einer Firma arbeiten. Und weißt du wie ein anderer Programmierer denkt und programmiert?

[Pseudemys Nelsoni]

wieso funktioniert das:

Delphi-Quellcode:

bla(socket.ReceiveText, ':', sl);
ListBox1.Items.AddStrings(sl);

aber das nicht:

Delphi-Quellcode:

ListBox1.Items.AddStrings(bla(socket.ReceiveText, ':', sl));

?

ist es nicht möglich das in eine zeile zu bekommen?

[choose]

Zitat:

Zitat von silent

[...]

Delphi-Quellcode:

ListBox1.Items.AddStrings(bla(socket.ReceiveText, ':', sl));

[...]
ist es nicht möglich das in eine zeile zu bekommen?

Hallo silent,

das funktioniert nur, wenn bla einen Rückgabewert vom Typ TStrings hätte. Ich rate Dir aber davon ab, den Parameter sl nach Result "durchzuschleifen"...
Wenn bla in dieser Art programmiert ist

Delphi-Quellcode:

procedure bla(const AnInputString: string; const ADelimiter: string; AResult: TStrings);
begin
  Assert(Assigned(AResult));
  AResult.BeginUpdate;
  try
    //append substrings from AnInputString to AResult seperated by ADelimiter
  finally
    AResult.EndUpdate;
  end;
end;

dann könntest Du die Funktion direkt mit den Items der Listbox verwenden:

Delphi-Quellcode:

Bla(socket.ReceiveText, ':', ListBox1.Items);

[Pseudemys Nelsoni]

danke ^^