Groß u. Kleinschreibung eines Strings umkehren

[himitsu]

Zitat von Satty67:

Ich hab' wieder mal auf möglichst wenige Variablen geachtet. Ist zwar sicher unwichtig

keine Sorge, bin nich neidisch, dafür hab ich doch möglichs wenige Funktionsaufrufe

das schnellste/kleinste vermutlich, wenn ich meine erste Version nach PChar oder gleich nach ASM konvertiere

Aber da du bei deinem Lower-/Uppercase jedes mal erst aus dem Char 'nen String machst und dann diese Funktionen auch noch mehrmals aufrufst, wird ein Aufruf dieser Funktionen schneller sein.

[Satty67]

Also hab's jetzt mal getestet...

meine Version ist die langsamste... und zwar mit Abstand die langsamste

[Sir Rufo]

Das war ja auch zu erwarten ... nicht weil du es gemacht hast sondern wie himitsu schreibt es eben zu 2*[LängeDesStrings] Aufrufen der Funktion UpperCase bzw. LowerCase kommt

Da ist natürlich eine Lösung, die diese Funktionen erst gar nicht nutzt (jaenicke), oder eben nur 2x aufruft (himitsu) wesentlich schneller.

Dafür ist die Lösung von Dir und himitsu auch Unicode-kompatibel und somit allgemeingültig

cu

Oliver

[himitsu]

jupp ruft 2*LängeDesStrings CharToStr und eine der Stringfunktionen(Lower/Upper) auf und diese Funktionen sind alle nicht unbedingt schnell.

Aber das langsamste ist hier eigentlich dieses interne CharToStr (Result[i] ist ja ein Char und Upper-/LowerCase wollen einen String, also muß erst ein String erstellt werden)

Code:

// Satty67's Funktion
function SwitchUpperLower(Str: String): String;
var
  i : Integer;
begin
  Result := Str;
  for i := 1 to Length(Result) do
    if UpperCase([b]CharToStr[/b](Result[i])) = Result[i] then
      Result[i] := LowerCase([b]CharToStr[/b](Result[i]))[1]
    else
      Result[i] := UpperCase([b]CharToStr[/b](Result[i]))[1];
end;

OK, das ist also nicht unbedingt schnell, aber vom Prinzip her isses nicht falsch und es funktioniert immerhin

[Satty67]

Zitat von Sir Rufo:

Das war ja auch zu erwarten ... nicht weil du es gemacht hast

Doch, liegt an mir bzw. meiner Art zu programmieren. Ich sehe den Code oft zu oberflächlich... aber da ich nichts kommerziell entwickle, darf ich das.

Mit himitsus Auflösung wird es deutlich, so sehe ich es dann auch.

[himitsu]

Ich arbeite auch meistens nicht kommerziell, das aktuelle Projekt ist sogar nur für mich alleine

Aber man lernt mit der Zeit und auch du wirst es in Zukunft (irgendwann) mal besser machen
(hab ja auch schon einige Jährchen an Lernprozessen und Fehlschlägen hinter mir)
Und wie gesagt, es funktionierte dennoch und das ist doch auch schonmal etwas

[Satty67]

Ob das noch besser wird

Programmier seit 1993 in Pascal (Turbo Pascal 6.0), allerdings mit teilweise monatelangen Pausen dazwischen. Da muss man wohl die Nettozeit sehen. Hab' nur im Moment wieder eine aktive Phase, weil ich mir eine Anwendung mit einer SQL-Datenbank schreibe.

[Luckie]

Warum weißt ihr alle schon gleich am Anfang Result einen Wert zu? Damit verliert der Compiler das EAX Register für den Rückgabewert. Wenn ihr eine Zwischenvariable nutzt, kann der Compiler besser optimieren, weil er noch ein zusätzliches Register zur Verfügung hat. Also so habe ich bisher gedacht. Sollte ich falsch liegen, bitte meine Aussage korrigieren.

[himitsu]

Wer sagt, daß Result immer (wärend der Laufzeit der Prozedur) in EAX liegt?

der Compiler legt es auch gerne mal auf'm Stack ab und kopiert erst am Ende nach EAX

PS: der Compiler verschiebt doch auch (oftmals) beim Start der Procedur die Parameter von den Registern auf den Stack.



OK, Turbo Pascal kenn ich auch noch ... sogar 'ne Zeit lang Basic/QBasic , aber CCBasic war wieder nett

[Satty67]

Zitat von Luckie:

Warum weißt ihr alle schon gleich am Anfang Result einen Wert zu?

Gemacht habe ich das, weil ich damit Result gleich richtig initialisiert hatte (auch bei Leerstring) und dazu kommt meine Manie, immer so wenig wie möglich Variablen zu verwenden.

Meine Priorität liegt wohl mehr auf "Übersichtlich" als "Effizient"

PS: Vor Pascal war eine kurze Zeit Basic for GEM-Desktop, also Windows-Programmierung vor Windows.