Effiziente Methode, einen String mittels Delimiter zu splitten

[Harry Stahl]

Ich war gerade auch auf der Suche danach, einen String zu splitten und einen Rückgabewert zu erhalten (für eine bestimmte Position im String), mittels einer Standard-Funktion in Delphi, um nicht immer direkt meine eigenen Units einbinden zu müssen, wenn man mal nur einen kleinen Demo-source zeigen möchte.

SplitString hatte ich dann in StrUtils gefunden, aber hier im Forum nochmal interessehalber mal nach "Splitstring" gesucht.

Und siehe da, String.Split ist natürlich noch viel schöner und außerdem schon in System.Sysutils drin, die automatisch eingebunden wird, wenn man eine neue Form anlegt.

Damit kann man das elegant so machen:

Delphi-Quellcode:

procedure TF_Main.Button1Click(Sender: TObject);
var
  s, Part: string;
begin
  s := '#Müller#Hans#Bonn';

  // bisher "GetFieldStr" aus meiner eigenen Unit
  // ShowMessage (GetFieldStr ('#', S, 2); // Müller, Zähung 1-basiert

  ShowMessage (Splitstring (S, '#')[1]); //Müller, Zählung 0-basiert

  // Noch kürzer geht es so
  ShowMessage (S.Split(['#'])[3]); // Bonn
end;

Etwas schade ist zwar, dass ein dynamisches Array für alle Teilstrings erzeugt wird, da ich eigentlich nur einen Eintrag brauche, aber wie gesagt, brauche keine extra Unit und wenn es nicht auf Performance ankommt, bzw. ein Demo zu gestalten, ohne Drittfunktionen zu brauchen, dann geht das schon mal so.

[Codehunter]

Zitat von Harry Stahl:

Etwas schade ist zwar, dass ein dynamisches Array für alle Teilstrings erzeugt wird, da ich eigentlich nur einen Eintrag brauche

In dem Fall wäre eine Regular Expression vielleicht besser geeignet?

[himitsu]

Und natürlich geht ohne Prüfung vor Zugriff sowas nicht, wenn es zu wenige Teilstrings gibt.
Aber hier könnte man auch einfach dafür sorgen, dass die Anzahl immer stimmt.
ShowMessage((S + '###').Split(['#'])[3]);

"Effizient" meint hier also schöner "kurzer" Code und wenige/keine externen Abhängigkeiten?

[Codehunter]

Zitat von himitsu:

ShowMessage((S + '###').Split(['#'])[3]);

Kürze und Schönheit müssen nicht gleichbedeutend sein. Ich wühle mich gerade an der Arbeit durch Code nach dem Prinzip "Effizienz durch Kürze". Die Eleganz und Wartbarkeit bewegt sich dabei irgendwo zwischen Assembler und Brainfuck. Die ein oder andere "sprechende" Variable mehr nehme ich jedenfalls dankbar an

[Harry Stahl]

Zitat von himitsu:

Und natürlich geht ohne Prüfung vor Zugriff sowas nicht, wenn es zu wenige Teilstrings gibt.
Aber hier könnte man auch einfach dafür sorgen, dass die Anzahl immer stimmt.
ShowMessage((S + '###').Split(['#'])[3]);

"Effizient" meint hier also schöner "kurzer" Code und wenige/keine externen Abhängigkeiten?

Mir ging es nicht um Schönheit, sondern nur um wenige/keine externen Abhängigkeiten.

Wenn ich ein lauffähiges Beispiel liefern möchte, für das der Anwender mit den Delphi-Standard-Units auskommen soll, dann wäre s.split also ein Ersatz für das, was ich sonst verwende (meine sonst verwendete GetFieldStr-Funktion hat natürlich verschiedene Absicherungen und liefert auch das richtige zurück, wenn weniger Felder als vermutet da).

Aber ansonsten: Natürlich kann ich auf Prüfung vor Zugriff verzichten, wenn ich definitiv weiß, dass der String mindestens die angeforderte Anzahl von Teilstrings enthält.

[Codehunter]

So dumm ist das gar nicht Bisher habe ich das immer mit Stringlisten gelöst und nach dem Splitten mit if Count >= Mindestanzahl geprüft.

Andererseits ist das auch wieder fallabhängig. Denn durch das Sicherstellen von einer Mindestanzahl nimmt man sich unter Umständen die Möglichkeit, Eingabefehler zu prüfen.

Kommt also immer auf den konkreten Einsatzzweck an.

[dummzeuch]

Zitat von Codehunter:

Zitat von Harry Stahl:

Etwas schade ist zwar, dass ein dynamisches Array für alle Teilstrings erzeugt wird, da ich eigentlich nur einen Eintrag brauche

In dem Fall wäre eine Regular Expression vielleicht besser geeignet?

Kurze Antwort: Nein.

Lange Antwort: Lineare Ausdrücke korrekt zu erstellen ist ein großer Aufwand, wenn man sowas nicht täglich macht. Es reicht, wenn man es ein-/zweimal falsch macht und nach dem Fehler sucht, um jeglichen Vorteil aufzuwiegen.

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems..