Case-Statement für Float-Werte

[Stevie]

Zitat:

Zitat von Andreas L. (Beitrag 1467397)

Liegt das "nur" am Daten-Typ oder wurde es einfach nicht im Compiler implementiert? Ich hatte mal einen PreCompiler (ich glaube es war IDE Fix Pack oder so ähnlich) mit dem man u. a. Strings in Case verwenden konnte. Das war vor über 10 Jahren... Warum baut Embarcadero sowas nicht mal ein? Floats, Strings, etc. Ich finde das wäre ein tolles Feature...

Das liegt daran, dass ein case nur für Ordinalwerte implementiert wurde und der Compiler eine Jumptable baut - in den Sprachen, die switch case auf mehr als das können, wird dann vom Compiler meist ähnlicher Code erzeugt, wie bei verschachtelten if-then-else Ausdrücken.
Leider ist es bei Delphi wie so oft ein schon lange gewünschtes, aber bisher nicht implementiertes Feature.

[Andreas13]

@Andreas L.:
Vielleicht ließe sich Dein Vorhaben auch wie folgt realisieren:
1:
Die AZoomFactor-Werte von Single in einen String mit nur 3 Ziffern umwandeln
2:
Dann würde die Fallunterscheidung für Strings mittels

Delphi-Quellcode:

Case AnsiIndexText(..)

funktionieren. Ein Beispiel hierfür findest Du hier: https://www.delphipraxis.net/67511-f...tels-case.html
Andreas

[himitsu]

Weil CASE im Delphi nur mit ordinalen Typen arbeitet, also Integer/Byte/Char/..., und das intern oft mathematisch (mit Addition/Substraktion) optimiert wird.

[Rollo62]

Zitat:

Zitat von haentschman (Beitrag 1467299)

Moin...:P

Zitat:

Wie kann ich das Problem lösen?

...den Eingangswert x 100 vor dem case. :wink:

Das sehe ich auch als Lösung an, also konkreter mal so in der Art:

Delphi-Quellcode:

function TfrmEditor.GetZoomFactorAsPercent(
  AZoomFactor: Single = 1): TibZoomFactorPercent;
begin
  Result := TibZoomFactorPercent.Custom;
  case Trunc(AZoomFactor * 100) of // Hier tritt der Fehler auf...
      10: Result := TibZoomFactorPercent.Percent10;
      25: Result := TibZoomFactorPercent.Percent25;
      50: Result := TibZoomFactorPercent.Percent50;
      75: Result := TibZoomFactorPercent.Percent75;
    100: Result := TibZoomFactorPercent.Percent100;
    125: Result := TibZoomFactorPercent.Percent125;
    150: Result := TibZoomFactorPercent.Percent150;
    175: Result := TibZoomFactorPercent.Percent175;
    200: Result := TibZoomFactorPercent.Percent200;
    250: Result := TibZoomFactorPercent.Percent250;
    300: Result := TibZoomFactorPercent.Percent300;
    400: Result := TibZoomFactorPercent.Percent400;
    500: Result := TibZoomFactorPercent.Percent500;
  end;

Alles mit "Wert = 0.10" KANN nicht funktionieren, also genausowenig mit case,
weil man float Werte nicht einfach vergleichen kann.
(Siehe unten die Vorschläge mit SameValue)
Deshalb wird es ein case mit float nicht geben können.

[Medium]

Um den Grund an sich noch mal auf den Punkt zu bringen:

CASE und IF sind nur funktional miteinander verwandt. CASE war ursprünglich mehr als nur eine andere (kürzere) Schreibart für eine Kette von IF-Statements, da es dem Compiler hier einfacher war effizienteren Maschinencode daraus zu generieren. Einschränkung: Da dafür Sprungtabellen (bestehend aus relativen Adressen, die halt immer ganzzahlig sind) aus den zu unterscheidenden Werten gebildet wurden/werden, waren/sind nur solche als Kriterium zulässig. In Zeiten, in denen jeder einzelne Prozessorzylus noch in vielfachen (Dollar-)Cents zu bemessen war, war das eine lukrative Angelegenheit.
Und auch heute noch sind solche "kleinkarierten" Optimierungen hier und da noch messbare Vorteile - jedoch werden diese immer seltener, und das Argument der einfacheren Schreib-/Lesbarkeit ist in den Vordergrund gerückt. Welcher Seite man als Compiler-Hersteller nun die Stange hält, ist meiner Meinung nach weitestgehend Geschmackssache. Delphi hat die Optimierbarkeit beibehalten, und somit die Beschränkung auf Ordinaltypen. Will man das nicht, muss man mit diesem Compiler etwas tricksen um die Lesbarkeit zu erhalten, oder einen anderen wählen und die Optimierbarkeit aufgeben.

[himitsu]

Es gäbe aber keinen Grund Beides nicht zu kombinieren.

Wenn der CASE-Wert Ordinal ist, dann den optimierten Code generieren,
und ansonsten könnte der Compilier das notfalls auch als viele IF-ElseIf-ElseIf-...-Else umsetzen,
bzw. für Strings in ein CASE mit IndexStr/IndexText übersetzen usw.

Denn wenn wir versuchen das Vorhaben so zu optimieren, damit es ins CASE passt,
dann kommt weniger lesbarer Code bei raus, als wenn das der Compilier intern anpassen würde.


Genauso wie es echt saudoof ist, dass IN immernoch als grauenhaftes SET-Assembler übersetzt wird, anstatt es optional mit BitMasken oder InArray umzusetzen.
Oder dass CharInSet intern nur Mist macht und man den Dreck nicht wieder entfernt, weil IN durch ein IN in einer Funktion zu ersetzen, welche einfach nur die CompilerWarnung unterdrückt, dass ist sowas von schwachsinnig nutzlos.
Wobei das CharInSet-Problem sofort behoben ist, wenn man für "IN WideChar" die grade erwähnte Verbesserung hätte, oder einfach die selbe Codeoptimierug verwenden würde, wie aktuell beim CASE.

[Rollo62]

Zitat:

Zitat von Medium (Beitrag 1467492)

Und auch heute noch sind solche "kleinkarierten" Optimierungen hier und da noch messbare Vorteile - jedoch werden diese immer seltener, ...

Ich denke CASE hat durchaus seine Berechtigung behalten, wenn mehrere, vieleicht > 3 Fälle bearbeitet werden müssen.
Das sollte immer schneller sein als sequentielles IF.

Falls du Recht hast das dies nicht schneller ist würde es doch bedeuten
das der Compiler das IF intern doch als Sprungtabelle optimiert, oder nicht ?

Schneller wäre vielleicht nur ein Auslagern in Prozeduren-Pointer, als einfache State-Machine
statt CASE oder IF, aber auch das bezweifele ich wenn im case nur wenig gemacht wird.
Da kann der Compiler doch perfekt optimieren (wenn er das könnte).

Die Sprungtebellen der CPU sollten doch das effektivste Mittel bleiben, oder habe ich da was verpasst ?
(Ich habe aber die letzten Jahre intensives CPU-Technologie Studium geschwänzt, Hauptsache das Ding läuft :stupid:)

[Medium]

Zitat:

Zitat von Rollo62 (Beitrag 1467499)

Zitat:

Zitat von Medium (Beitrag 1467492)

Und auch heute noch sind solche "kleinkarierten" Optimierungen hier und da noch messbare Vorteile - jedoch werden diese immer seltener, ...

Ich denke CASE hat durchaus seine Berechtigung behalten, wenn mehrere, vieleicht > 3 Fälle bearbeitet werden müssen.
Das sollte immer schneller sein als sequentielles IF.

Schneller wird es wohl sein. Aber die Wichtigkeit minimaler Geschwindigkeitsunterschiede zu Codeles- und wartbarkeit ist dank der immensen Gesamtgeschwindigkeit der Rechner nicht mehr dieselbe wie damals. (Natürlich gibt es Situationen, in denen das noch immer merkbar ist, wo sich jeder wegoptimierte Zyklus lohnt. Aber das sind eine Hand voll spezieller Dinge fernab des Tagesgeschäftes der meisten Entwickler.)

Edit: Um das klar zu stellen: Ich sage nicht, dass case schlechter lesbar ist als if-Kaskaden. Aber ein "auf deubel komm raus" Klimmzug um mit eigentlich nicht passenden Typen es dennoch irgendwie in ein case zu pressen verliert definitiv zumindest an Wartbarkeit, da man Umwege einführt die man ggf. als Dritter nicht erwartet, und jede zusätzliche Zeile Code wieder eine mögliche Fehlerquelle mehr ist.

[Neutral General]

Es gibt ja keinen Grund nicht beides haben zu können. Wenn es ein Ordinalwert ist macht der Compiler alles wie bisher. Wenns kein Ordinalwert ist, wirds intern eben wie ein verschachteltes if-else behandelt.

[Stevie]

Zitat:

Zitat von Medium (Beitrag 1467516)

Edit: Um das klar zu stellen: Ich sage nicht, dass case schlechter lesbar ist als if-Kaskaden. Aber ein "auf deubel komm raus" Klimmzug um mit eigentlich nicht passenden Typen es dennoch irgendwie in ein case zu pressen verliert definitiv zumindest an Wartbarkeit, da man Umwege einführt die man ggf. als Dritter nicht erwartet, und jede zusätzliche Zeile Code wieder eine mögliche Fehlerquelle mehr ist.

Korrekt - deshalb liegt guten Designern und Entwicklern von Programmiersprachen sehr viel daran, Syntax ggf zu erweitern, dass man Dinge intuitiv schreiben kann, ohne Klimmzüge zu machen, siehe Pattern Matching in C#.