| Autor |
Nachricht |
schumann.vas
      
Beiträge: 43
Win 2000, Win XP, Win 7; Ubuntu
Delphi 7, Delphi XE2, C
|
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:
meine versuchte case-Anweisung:
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
Zuletzt bearbeitet von schumann.vas am Do 10.11.11 15:31, insgesamt 1-mal bearbeitet
|
| |
|
|
Werbung ausblenden? Dann registriere Dich kostenlos.
Weitere Gründe für eine Registrierung.
Werbung ausblenden? Dann registriere Dich kostenlos.
Weitere Gründe für eine Registrierung.
|
|
vagtler
       
Beiträge: 64
Erhaltene Danke: 18
|
Verfasst: Do 10.11.11 15:28
Du kannst für case-Anweisungen nur Ordinaltypen verwenden.
|
| |
|
|
schumann.vas 
      
Beiträge: 43
Win 2000, Win XP, Win 7; Ubuntu
Delphi 7, Delphi XE2, C
|
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: 204
Erhaltene Danke: 22
OpenSUSE 11.4
Lazarus 0.9.31
|
Verfasst: Do 10.11.11 15:36
Geht nicht.
Nur feste Werte und Bereiche (mit a..b)
|
| |
|
|
glotzer
       
Beiträge: 287
Erhaltene Danke: 31
Win 7
Delphi XE, Delphi 7, Delphi 3; Lazarus
|
Verfasst: Do 10.11.11 15:45
ich hätte ja eine idee aber die ist nicht wirklich schön:
_________________ ja, ich schreibe grundsätzlich alles klein und meine rechtschreibfehler sind absicht
|
| |
|
|
bummi
      
Beiträge: 980
Erhaltene Danke: 124
XP - Server 2008R2
D2 - Delphi XE
|
Verfasst: Do 10.11.11 15:48
_________________ Das Problem liegt üblicherweise zwischen den Ohren
DRY DRY KISS
|
| |
|
|
Gammatester
       
Beiträge: 122
Erhaltene Danke: 14
|
Verfasst: 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):
Der Zweig (result := 5) wird nicht erreicht und kann weggelassen werden.
|
| |
|
|
schumann.vas 
      
Beiträge: 43
Win 2000, Win XP, Win 7; Ubuntu
Delphi 7, Delphi XE2, C
|
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
      
Beiträge: 15843
Erhaltene Danke: 742
XP, W7 x64 (Chrome, IE9, FF), Debian, (OSX 10.7)
RAD XE 2, Java (NB), C++, C# (VS 2010), JS/HTML, PHP, Lazarus
|
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. 
|
| |
|
|
Tranx
       
Beiträge: 309
Erhaltene Danke: 22
WIN 2000, WIN XP
D5 Prof
|
Verfasst: Fr 11.11.11 03:20
Statt dieser Case-Anweisung:
Warum nicht mit Array?
_________________ Toleranz ist eine Grundvoraussetzung für das Leben.
|
| |
|
|
bummi
      
Beiträge: 980
Erhaltene Danke: 124
XP - Server 2008R2
D2 - Delphi XE
|
Verfasst: Fr 11.11.11 06:24
@Tranx
hast Du meinen Beitrag gesehen?
_________________ Das Problem liegt üblicherweise zwischen den Ohren
DRY DRY KISS
|
| |
|
|
bole
      
Beiträge: 83
Erhaltene Danke: 3
win 2000, win xp
Turbo Delphi 2006
|
Verfasst: Fr 11.11.11 10:57
Hallo
Gemäss schumann.vas ging es um die Übersichtlichkeit
schumann.vas 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
       
Beiträge: 64
Erhaltene Danke: 18
|
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: 83
Erhaltene Danke: 3
win 2000, win xp
Turbo Delphi 2006
|
Verfasst: 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.
_________________ ein programm macht nicht das was du willst sondern was du schreibst!
|
| |
|
|
delfiphan
       
Beiträge: 2682
Erhaltene Danke: 26
|
Verfasst: 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).
|
| |
|
|