Entwickler-Ecke
Delphi Language (Object-Pascal) / CLX - if-Anweisung in case-Anweisung umwandeln
xsus - Do 10.11.11 15:07
Titel: if-Anweisung in case-Anweisung umwandeln
Hey, ich möchte folgende if - Anweisung in eine case-Anweisung umwandeln. Doch stolper ich da über ein paar Probleme..weiß vielleicht jmd mehr ?^^
if-Anweisung:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
| function tarif(gewicht:real):byte;
begin
if gewicht<=0 then
result:=0 else
if (gewicht<=10) then
result:=1 else
if (gewicht<=20) then
result:=2 else
if (gewicht>20) and (gewicht<=100) then
result:=3 else
if (gewicht>100) then
result:=4 else
result:=5;
end; |
meine versuchte case-Anweisung:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
| function tarif(gewicht:real):byte;
begin
case gewicht of
<0: begin
result:=0;
end;
>0..10: begin
result:=1;
end;
>10..20: begin
result:=2;
end;
>20..100: begin
result:=3;
end;
>100: begin
result:=4;
end;
end;
end; |
Hoffentlich weiß jmd wie ich das richtig machen muss ;) ...also ich weiß ja aus der Fehlermeldung das ich kleiner/größer als und sowas nicht nehmen kann,wie mach ich das dann? und wie schaff ich es das ich diese typen behalten kann ohne auf integer umsteigen zu müssen?
Lg
Moderiert von 
Christian S.: Topic aus Algorithmen, Optimierung und Assembler verschoben am Do 10.11.2011 um 14:11
vagtler - Do 10.11.11 15:28
Du kannst für case-Anweisungen nur Ordinaltypen verwenden.
xsus - Do 10.11.11 15:31
Ich weiß...das sagt auch die Fehlermeldung! ;)....nur ich muss bei der Function real mit Ausgabewert byte behalten...gibt es da keine möglichkeit eine schöne case Anweisung zu machen? und wäre das problem mit dem ordinalem typ nicht, wie definiere ich in einer case-Anweisung kleiner/größer als/gleich...?! LG
Teekeks - Do 10.11.11 15:36
Geht nicht.
Nur feste Werte und Bereiche (mit a..b)
glotzer - Do 10.11.11 15:45
ich hätte ja eine idee aber die ist nicht wirklich schön:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
| function tarif(gewicht:real):byte;
begin
case round(gewicht) of
-MaxInt..0:
begin
result:=0;
end;
0..10: begin
result:=1;
end;
10..20: begin
result:=2;
end;
20..100: begin
result:=3;
end;
100..MaxInt:
begin
result:=4;
end;
end;
end; |
bummi - Do 10.11.11 15:48
vielleicht so was
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
| Function FloatCase(value:Double; FloatArray : Array of Double):Integer;
var
i:Integer;
begin
Result := 0;
for i := Low(FloatArray) to High(FloatArray) do
if value > FloatArray[i] then inc(Result);
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
case FloatCase(17,[0,10,20,30]) of
0:Showmessage('0');
1:Showmessage('1');
2:Showmessage('2');
end;
end; |
Gammatester - Do 10.11.11 15:52
Warum willst Du eine case-Anweisung? Wegen der Übersichtlichkeit? Dann schreib doch Deinen Originalcode um (ohne überflüssige Abfragen und Klammern):
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
| function tarif(gewicht: real): byte;
begin
if gewicht <= 0 then result := 0
else if gewicht <= 10 then result := 1
else if gewicht <= 20 then result := 2
else if gewicht <= 100 then result := 3
else result := 4;
end; |
Der Zweig (result := 5) wird nicht erreicht und kann weggelassen werden.
xsus - Do 10.11.11 18:52
danke erstmal :) ...ja es ging mir rein um die übersichtlichkeit und um das lernen im umgang mit case-Anweisungen
jaenicke - Do 10.11.11 19:08
Was die Übersichtlichkeit angeht würde es schon helfen, wenn du dich an die Formatierungskonventionen halten würdest. ;-)
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
| function CalculateRate(AWeight: Double): Byte;
begin
if AWeight <= 0 then
Result := 0
else if AWeight <= 10 then
Result := 1
else if AWeight <= 20 then
Result := 2
else if AWeight <= 100 then
Result := 3
else
Result := 4;
end; |
Tranx - Fr 11.11.11 03:20
Statt dieser Case-Anweisung:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
| function tarif(gewicht:real):byte;
begin
case gewicht of
<0: begin
result:=0;
end;
>0..10: begin
result:=1;
end;
>10..20: begin
result:=2;
end;
>20..100: begin
result:=3;
end;
>100: begin
result:=4;
end;
end;
end; |
Warum nicht mit Array?
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
| function tarif(gewicht:real):byte;
const
Grenze : Array[0..4] of real = (0, 10, 20, 100, MaxInt);
var
i : integer;
begin
Result := 0;
for i := 0 to 4 do
begin
if Gewicht <= Grenze[i] then
begin
Result := i;
break;
end;
end;
end; |
bummi - Fr 11.11.11 06:24
@Tranx
hast Du meinen Beitrag gesehen?
bole - Fr 11.11.11 10:57
Hallo
Gemäss
xsus ging es um die Übersichtlichkeit
xsus hat folgendes geschrieben  : |
| danke erstmal :) ...ja es ging mir rein um die übersichtlichkeit und um das lernen im umgang mit case-Anweisungen |
Diese 4 Entscheidungen mit Arrays und Schleifen zu programmieren ist wohl alles andere als übersichtlich und wartungsfreundlich! Zu Übungszwecken mag das Ok sein aber in produktiver Software sollte das
KISS Prinzip [
http://de.wikipedia.org/wiki/KISS-Prinzip] zur Anwendung kommen.
Gruss
Bole
vagtler - Fr 11.11.11 12:23
| bole hat folgendes geschrieben : |
| [...] Diese 4 Entscheidungen mit Arrays und Schleifen zu programmieren ist wohl alles andere als übersichtlich und wartungsfreundlich! [...] |
Das mag Ansichtssache sein, aber mit wenigen Änderungen ist genau das die wartungsfreundlichste aller Lösungen. KISS bedeutet nicht zwangsläufig den Einsatz der einfachsten und dümmsten aller Lösungen. KISS sollte immer mit MAYA in Betracht gezogen werden.
bole - Fr 11.11.11 22:28
| vagtler hat folgendes geschrieben : |
| KISS bedeutet nicht zwangsläufig den Einsatz der einfachsten und dümmsten aller Lösungen. KISS sollte immer mit MAYA in Betracht gezogen werden. |
Wenn eine kompliziertere Lösung gewählt wird sollte diese einen Mehrwert bringen. Den kann ich hier beim besten Willen nicht erkennen... Meiner Meinung nach ist in diesem Fall die komplizierte Lösung die dümmere!
Ich arbeite im 2. Level Support eines grossen Finanzdienstleisters und erlebe das fast jeden Tag. Es gibt viele Programmierer die aus eine Mücke einen Elefant machen können, sprich ein relativ einfaches Problem auf die komplizierteste Art zu lösen... Unter Wartungsfreundlich verstehe ich, dass man die einfachste für alle sofort verständlichste Lösung wählt die das Problem löst.
delfiphan - Sa 12.11.11 01:05
Wenn man Software von professionellen Entwicklern schreiben lässt, werden Tarife hoffentlich nicht in der ganzen Applikation in irgendwelchen Funktionen hart codiert.
Die zweite Array-Lösung finde ich unschön, unüblich, buggy und hat einen merkwürdigen Namen.
1. Eine globale, unkommentierte Funktion "tarif", die einen real-Wert "gewicht" nimmt und ein Byte zurückgibt. Wenn man den Code nicht anschaut weiss man nicht, was die Funktion tut. Wartungsfreundlich ist das schon mal nicht.
2. Die Obergrenze "MaxInt" bei real ist offensichtlich ein misslungener Workaround oder eine schlechte Notlösung, auf jeden Fall ein Bug.
3. Die Funktion hardcodiert die Grenzen und die Limits. Riskant.
4. Wenn die Funktion einen Index zurück gibt, dann wäre Integer der richtige Typ. Dasselbe gilt für real/Double.
Die Funktion von bummi gefällt mir bis auf die Namen schon viel besser. Über den "korrekten" Rückgabewert bei einem leeren Array und die implizit erforderliche Sortierung könnte man noch streiten (auf jeden Fall dokumentationswürdig).
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!