Stringfunktionen

[relocate]

Zitat:

Zitat von Bummi (Beitrag 1163354)

@Iwo Asnet

Ein Hinweis für unerfahrene 2009+ Anwender, sollte noch gegeben werden

Dann mal her mit dem Hinweis, auch wenn ich kein unerfahrener und kein Anwender von 2009+ bin.

[shmia]

Die Jedi Code Library enthält umfangreiche Stringfunktionen und Vieles anderes mehr. :thumb:
Ich verwende unter D5 noch die Version 1.0.4, weil ich mit den (damals) neuen 2.0x Versionen Probleme hatte.
Auf jeden Fall erhälst du mit der JCL ein volles Paket an Units mit vielen nützlichen Funktionen.
Dein Programm wird dabei kaum grösser, weil der Linker nur die Funktionen dazulinkt, die du auch benützt hast.

[relocate]

Zitat:

Zitat von UliBru (Beitrag 1163363)

JCLStrings ?
Eigene Beiträge sind vermutlich ab einer bestimmten Qualität sicher machbar. Siehe auch hier

Tolle Unit, aber die Assemblerumsetzungen sind denn eher nicht zum lernen geeignet. Eine fertige Unit meinte ich eben nicht mit einer Sammlung, schon eine aus der man lernen kann. Und die JCL erschlägt einen sowieso.

[relocate]

Zitat:

Zitat von shmia (Beitrag 1163365)

Die Jedi Code Library enthält umfangreiche Stringfunktionen und Vieles anderes mehr. :thumb:
Ich verwende unter D5 noch die Version 1.0.4, weil ich mit den (damals) neuen 2.0x Versionen Probleme hatte.
Auf jeden Fall erhälst du mit der JCL ein volles Paket an Units mit vielen nützlichen Funktionen.
Dein Programm wird dabei kaum grösser, weil der Linker nur die Funktionen dazulinkt, die du auch benützt hast.

Bei den fetten Programmen mit der VCL (zumindest in D5) spielt das wohl kaum eine Rolle, aber bei meinen NonVCL Anwendungen nicht verkehrt. Guter Hinweis mit den Versionsproblemen (noch so ein Ding was mich von fertigen Komponenten/Units abschreckt).

[himitsu]

Zitat:

1. Wird meine Variante nicht unbedingt die schnellste sein, da ich kein Profi Entwickler bin
2. Gibt es mit Sicherheit schon mehrere Implementationen, auch wenn die vielleicht erst auf der Googlesuchseite 10 steht.
3. Weiß ich dann immer noch nicht, welche die Schnellste ist.

Wobei es ja auch nicht immer um Schnelligkeit geht.

Denn es kommt auf den Einsatzzweck drauf an.
- wird es sehr oft aufgerufen, dann könnte es schon wichtig sein
- ist die zeit egal, dann ist auch die Geschwindigkeit egal (bzw. es muß nicht unbedingt das Allerschnellste sein)
- und manchmal reicht es, wenn es ausreichend flott ist, aber man dafür wartbaren code bekommt, welchen man eventuell auch noch selber versteht.

Ansonsten kannst du ja immernoch nachmessen, bzw. etwas nehmen, was dir vom Code her gefällt und sollte es doch noch geschwindigkeitsprobleme geben, dann könnte man immer noch nachsehn was schneller/optimaler ist.



Wie es schon erwähnt wurde:
Wenn es um einzelne Funktionen geht, dann bieten die Forensuche, die CL, sowie Google und die anderen Delphi-Webseiten sehr viel.
Und notfalls fragt man eben hier geziehlt nach.

[DeddyH]

Zunächst muss eine Routine zuverlässig funktionieren, danach kann man dann sehen, wie man die Geschwindigkeit ggf. erhöhen könnte. Dreht man diese Reihenfolge um, kommt selten etwas Brauchbares dabei heraus.

Zitat:

Zitat von Donald Knuth

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

[relocate]

Zitat:

Zitat von himitsu (Beitrag 1163373)

Zitat:

1. Wird meine Variante nicht unbedingt die schnellste sein, da ich kein Profi Entwickler bin
2. Gibt es mit Sicherheit schon mehrere Implementationen, auch wenn die vielleicht erst auf der Googlesuchseite 10 steht.
3. Weiß ich dann immer noch nicht, welche die Schnellste ist.

Wobei es ja auch nicht immer um Schnelligkeit geht.

Denn es kommt auf den Einsatzzweck drauf an.

Das hatte ich ja auch geschrieben, nicht unterschlagen beim Zitieren. :-D

"Nicht nur in dem Bereich wäre also eine Sammlung interessant die
mehrere Lösungen präsentiert und dies vielleicht sogar mit Performenzangaben je nach Verwendungszweck."

Zitat:

Zitat von himitsu (Beitrag 1163373)

- wird es sehr oft aufgerufen, dann könnte es schon wichtig sein
- ist die zeit egal, dann ist auch die Geschwindigkeit egal (bzw. es muß nicht unbedingt das Allerschnellste sein)
- und manchmal reicht es, wenn es ausreichend flott ist, aber man dafür wartbaren code bekommt, welchen man eventuell auch noch selber versteht.

Das ist der Fall, bzw. kann immer der Fall sein, weshalb der optimale Algorithmus (was auch immer das dann sein mag) immer gut wäre. Im Fall einer Sammlung ja auch gut zu wissen und bei Quick and Dirty kann es schon bei einem Aufruf "extreme" Unterschiede geben. Und eine Quick and Dirty Variante kann unter Umständen komplizierter und schwer verständlicher sein, als eine optimierte Variante.

Zitat:

Zitat von himitsu (Beitrag 1163373)

Ansonsten kannst du ja immernoch nachmessen, bzw. etwas nehmen, was dir vom Code her gefällt und sollte es doch noch geschwindigkeitsprobleme geben, dann könnte man immer noch nachsehn was schneller/optimaler ist.

Wie es schon erwähnt wurde:
Wenn es um einzelne Funktionen geht, dann bieten die Forensuche, die CL, sowie Google und die anderen Delphi-Webseiten sehr viel.
Und notfalls fragt man eben hier geziehlt nach.

Klar, aber bei einer Sammlung wäre es dann schon schön, wenn man so etwas dabei stehen hat, mit einem Beispiel. Tja, da ist eben das Problem, man muss sich aus allen Ecken und Enden was zusammen suchen, was eigentlich zusammen gehört. Das Problem mit Google habe ich schon angegeben, das Ergebnis passt nicht immer auf die Suche, immer seltener wie ich finde. Und auch die Code Library hier ist nicht sehr optimal geordnet. Und gefragt habe ich, aber sowas führt zu immer mehr Einträgen die eigentlich schon beantwortet sind und zu immer mehr überladenen Ergebnissen bei Suchmaschinen.

[relocate]

Zitat:

Zitat von DeddyH (Beitrag 1163374)

Zunächst muss eine Routine zuverlässig funktionieren, danach kann man dann sehen, wie man die Geschwindigkeit ggf. erhöhen könnte. Dreht man diese Reihenfolge um, kommt selten etwas Brauchbares dabei heraus.

Klar, Zuverlässigkeit steht an erster Stelle, leider leidet die Effizienz immer mehr, die neue Hardware bügelt das ja schon aus.

Ich habe mal ein Char aus einem String herausgelöst. Was bei einem Leerstring eine Exception wirft, also muss das getestet werden. Ich habe das mit folgenden Varianten gemacht:

1)

Delphi-Quellcode:

if wort = '' then chrtest := #0
else chrtest := wort[1];

2)

Delphi-Quellcode:

if wort <> '' then chrtest := wort[1]
else chrtest := #0;

3)

Delphi-Quellcode:

if length(wort)=0 then chrtest := #0
else chrtest := wort[1];

4)

Delphi-Quellcode:

if length(wort)>0 then chrtest := wort[1]
else chrtest := #0;

5)

Delphi-Quellcode:

try 
  chrTest := wort[1];
except
  chrTest := #0;
end;

Auf meinem PC war die Variante 2 die schnellste, wenn auch nur unwesentlich schneller als 1.
Variante 4 hat ungefähr doppelt solange gedauert, wiederum unwesentlich schneller als 3.
Der Try Block etwas langsamer noch als 3/4 (außer die Exception wurde geworfen, das hat gedauert).

Wenn der Fall eintrat dass der String leer war erhöhte sich die Abarbeitungszeit.

Auf einem anderen, älteren PC war das anders. Die Variante 1 und 2 wurden deutlich schneller bei einem Leerstring. Und die Varianten 3 und 4 etwas schneller. Also ist auch noch relevant wie man testet und welcher der Ziel PC ist. Der Try Block war auch da langsamer bei einer Exception.

[himitsu]

Zitat:

Delphi-Quellcode:

try
  chrTest := wort[1];
except
  chrTest := #0;
end;

Sowas sollte man auch niemals machen.
Denn fang jetzt mal an dein Programm zu debuggen, wenn da genügend solcher Code drin vorkommt,
dann kannst'e dich auch gleich erschießen, denn sowas macht absolut keinen Spaß mehr.

Im Fall von Zahlen ist das sehr gut beobachtbar:

Delphi-Quellcode:

try
  i := StrToInt(s);
except
  i := 0;
end;

// oder

i := StrToIntDef(s, 0);

Delphi-Quellcode:

try
  i := StrToInt(s);
  {mach was mit i}
except
end;

// oder

if TryStrToInt(s, i) then
  {mach was mit i}

Vorallem leere except-end-Blöcke sind grauenhaft.


Bezüglich der Unterschiede zwischen = und <>.
Dort hängt es sehr von den Eingangsdaten ab.
Da ist mir persönlich fast immer alles egal und ich verwende die Variante, welche ich besser lesen kann. Außerdem versuche ich durchgängig nur eine Variante zu verwenden, weil man den gesamten Code dadurch auch besser verstechen kann. (man verliest sich weniger)

[relocate]

Zitat:

Zitat von himitsu (Beitrag 1163382)

Zitat:

Delphi-Quellcode:

try
  chrTest := wort[1];
except
  chrTest := #0;
end;

Sowas sollte man auch niemals machen.
Denn fang jetzt mal an dein Programm zu debuggen, wenn da genügend solcher Code drin vorkommt,
dann kannst'e dich auch gleich erschießen, denn sowas macht absolut keinen Spaß mehr.

Ich bin auch kein Freund von den Try-Blöcken. Ich hatte ja geschrieben, ich kam von Turbo Pascal 6, da gab es solche feinen Sachen noch nicht. Na ja, nicht direkt. Da musste z.B. die I/O Kontrolle ausgeschaltet werden und über IOResult das Ergebnis abgefragt. Ist quasi ein Try Except Block. Aber in diesem Fall funktioniert es ja. Ich kam darauf, weil ja eine Exception stattfand, also konnte es damit abgefangen werden. Allerdings finde ich, wer das so nutzt ist zu Faul sauber zu programmieren. In manchen Fällen wohl aber nicht zu vermeiden.

Zitat:

Zitat von himitsu (Beitrag 1163382)

Im Fall von Zahlen ist das sehr gut beobachtbar:

Delphi-Quellcode:

try
  i := StrToInt(s);
except
  i := 0;
end;

// oder

i := StrToIntDef(s, 0);

Delphi-Quellcode:

try
  i := StrToInt(s);
  {mach was mit i}
except
end;

// oder

if TryStrToInt(s, i) then
  {mach was mit i}

Vorallem leere except-end-Blöcke sind grauenhaft.

Das mit den Zahlen schaue ich mir mal an, habe mir das aber mit dem Code den ich gepostet habe auch gemacht. Ich fand jetzt die Abfrage nach ='' so billig :lol: mit Length hat mehr Stil, ich benutze aber trotzdem ='' und das mit den leeren Except Blöcken ist logisch.

Zitat:

Zitat von himitsu (Beitrag 1163382)

Bezüglich der Unterschiede zwischen = und <>.
Dort hängt es sehr von den Eingangsdaten ab.
Da ist mir persönlich fast immer alles egal und ich verwende die Variante, welche ich besser lesen kann. Außerdem versuche ich durchgängig nur eine Variante zu verwenden, weil man den gesamten Code dadurch auch besser verstechen kann. (man verliest sich weniger)

In diesem Fall gab es ja kaum Zeitunterschiede, aber auch das ist klar. Man prüft besser auf den Sonderfall und den Standardfall lässt man so durch gehen (ich habe es irgendwo besser formuliert stehen).