Case-Statement für Float-Werte

[Medium]

Zitat von Rollo62:

Zitat von Medium:

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.

[stahli]

Entweder Round(AZoomFactor * 100) oder

mehrere if´s in dieser Form:

Delphi-Quellcode:

function TfrmEditor.GetZoomFactorAsPercent(
  AZoomFactor: Single = 1): TibZoomFactorPercent;
begin
  Result := TibZoomFactorPercent.Custom;

  if (AZoomFactor = 0.10) then Exit(TibZoomFactorPercent.Percent10);
  if (AZoomFactor = 0.25) then Exit(TibZoomFactorPercent.Percent25);
...
end;

Im Grunde ist die zweite Variante noch übersichtlicher.
Sie ist etwas aufwendiger zu tippen, aber das ist ja ein einmaliger Aufwand. Man ist auch etwas freier in der Ausgestaltung.

Zu beachten ist, dass Floatwerte immer Ungenauigkeiten beinhalten können.
Deshalb sollte man ggf. eine Funktion wie SameValue zum Vergleich verwenden.

[himitsu]

Und statt AZoomFactor = 0.10 bei Floats besser mit SameValue rumspielen.

[Andreas L.]

Danke für eure vielen Antworten. Das ich mit ganzen Prozenten oder mit If-Abfragen das Problem lösen kann war mir von Anfang an klar. Ich wollte nur wissen warum es nicht möglich ist Float-Werte in einem Case-Statement zu verwenden. Ebenso Strings. 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...

[stahli]

Ja, ich fände das auch gut.

Es würde sich ja lediglich um eine andere Schreibweise von if-Statements handeln.
Der Compiler könnte quasi identischen Maschinencode wie bei if-Statements erzeugen.

Schwieriger wäre sicherlich, das auch dem Debugger beizubringen.

Wie hoch der Aufwand letztlich in Summe wäre, kann ich nicht wirklich beurteilen.

[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 Case AnsiIndexText(..) funktionieren. Ein Beispiel hierfür findest Du hier: https://www.delphipraxis.net/67511-f...tels-case.html
Andreas

[Stevie]

Zitat von Andreas L.:

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.

[himitsu]

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