if-Anweisung in case-Anweisung umwandeln

xsus · Verfasst: Do 10.11.11 15:07

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:

markieren

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:

markieren

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 · Verfasst: Do 10.11.11 15:28

Du kannst für case-Anweisungen nur Ordinaltypen verwenden.

xsus · Verfasst: 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 · Beiträge: 211 Erhaltene Danke: 23

Geht nicht.

Nur feste Werte und Bereiche (mit a..b)

glotzer · Beiträge: 393 Erhaltene Danke: 49 Win 7 Lazarus

ich hätte ja eine idee aber die ist nicht wirklich schön:

markieren

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;

_________________
ja, ich schreibe grundsätzlich alles klein und meine rechtschreibfehler sind absicht

bummi · Verfasst: Do 10.11.11 15:48

vielleicht so was

markieren

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;

_________________
Das Problem liegt üblicherweise zwischen den Ohren H₂♂
DRY DRY KISS

Gammatester · Beiträge: 328 Erhaltene Danke: 101

Warum willst Du eine case-Anweisung? Wegen der Übersichtlichkeit? Dann schreib doch Deinen Originalcode um (ohne überflüssige Abfragen und Klammern):

markieren

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 · Verfasst: 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 · Verfasst: Do 10.11.11 19:08

Was die Übersichtlichkeit angeht würde es schon helfen, wenn du dich an die Formatierungskonventionen halten würdest. ;-)

markieren

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 · Verfasst: Fr 11.11.11 03:20

Statt dieser Case-Anweisung:

markieren

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?

markieren

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;

_________________
Toleranz ist eine Grundvoraussetzung für das Leben.

bummi · Verfasst: Fr 11.11.11 06:24

@Tranx

hast Du meinen Beitrag gesehen?

_________________
Das Problem liegt üblicherweise zwischen den Ohren H₂♂
DRY DRY KISS

bole · Beiträge: 107 Erhaltene Danke: 15 win 10

Hallo

Gemäss user profile icon

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 zur Anwendung kommen.

Gruss
Bole

_________________
ein programm macht nicht das was du willst sondern was du schreibst!

vagtler · Verfasst: 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 · Beiträge: 107 Erhaltene Danke: 15 win 10

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.

_________________
ein programm macht nicht das was du willst sondern was du schreibst!

delfiphan · Beiträge: 2684 Erhaltene Danke: 32

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).

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme