Moin Moin,
Leider ist es ja in C nicht möglich eine Switch-Case Anweisung mit
Vergleichsoperatoren zu verwenden. D.h. man muss in diesem Falle viele
if's hintereinander abarbeiten.
Nun hab ich mir gedacht, dass es ja eigentlich blöd ist, wenn gleich die
erste if-Anweisung "true" ist, dass dann die darauf folgenden
unnötigerweise immer mit abgearbeitet werden.
Jetzt hab ich das ganze einfach mal in eine Schleife gepackt und mit
break;-Anweisungen ausgeschmückt.
Meine Frage: wie sinnvoll ist das? Schluckt die Schleife drumherum evntl
sogar mehr "Ressource" als die eingespartet if-Anweisungen??
anbei mal der Code. (Zahlendarstellung auf einem GLCD)
1
// "." = Plathalter für Minus-Zeichen (8px) ; "/" = Platzhalter für Ziffer (14px)
2
// damit Darstellung Rechtsbündig vor dem Komma ist.
3
4
while(1)//Switch-Case der Marke Eigenbau, für Vergleichsoperatoren
5
{
6
if(position>=10000)//100er Stelle
7
{
8
lcd_puts_p(numbersbig,PSTR("."));
9
break;
10
}
11
if(position<10000&&position>=1000)//10er Stelle
12
{
13
lcd_puts_p(numbersbig,PSTR("./"));
14
break;
15
}
16
if(position>=0&&position<1000)//1er Stelle
17
{
18
lcd_puts_p(numbersbig,PSTR(".//"));
19
break;
20
}
21
if(temp<=(-10000))//-100er Stelle Sonderfall, maximale Anzahl an Stellen
22
{
23
break;
24
}
25
if(position<=(-1000)&&position>(-10000))//-10er Stelle
26
{
27
lcd_puts_p(numbersbig,PSTR("/"));
28
break;
29
}
30
if(position<=(-100)&&position>(-1000))//-1er Stelle
31
{
32
lcd_puts_p(numbersbig,PSTR("//"));
33
break;
34
}
35
if(position<0&&position>(-100))//-1er Stelle Sonderfall -0.xx
Mal abgesehen vom else.
Welche Schleife denn? Die wird doch gar nicht ausgeführt.
Wenn du wirklich meinst, der Compiler prüft da wirklich auf 1, dann mach
eine do-whhile(0)-Schleife.
Schreib aber bitte ganz ausführlich in deinen Code was dieses Konstrukt
bezwecken soll, damit man den in drei Wochen auch noch versteht.
Die if-break-Kette enthält zimelich viel Redundanz. Eine Abfrage über
mehrere aneinander angrenzende Intervalle macht man üblichweise so, dass
man die Intervallgrenzen der Größe nach sortiert und jede Grenze in
einer if-elseif-Kette genau einmal abfragt:
1
if(position>=10000)//100er Stelle
2
lcd_puts_p(numbersbig,PSTR("."));
3
elseif(position>=1000)//10er Stelle
4
lcd_puts_p(numbersbig,PSTR("./"));
5
elseif(position>=0)//1er Stelle
6
lcd_puts_p(numbersbig,PSTR(".//"));
7
elseif(position>-100)//-1er Stelle Sonderfall -0.xx
Henning schrieb:> damit Darstellung Rechtsbündig vor dem Komma ist.
printf kann bereits rechtsbündig ausgeben.
Man muß nicht alles zu Fuß nachprogrammieren, sondern darf die Libs
benutzen.
Peter Dannegger schrieb:> Man muß nicht alles zu Fuß nachprogrammieren, sondern darf die Libs> benutzen.
Wobei man manchmal versucht ist, ausgerechnet printf zu vermeiden.
Henning schrieb:> wie sinnvoll ist das?
Welchen Unterschied sollen die wenigen Bytes/Takte bewirken? Der
GLCD-Code ist wahrscheinlich um Größenordnungen größer/langsamer als die
paar Vergleiche und Sprünge.
> Schluckt die Schleife drumherum evntl> sogar mehr "Ressource" als die eingespartet if-Anweisungen??
Die knappste Resource ist meistens zukünftige Lesbarkeit. Und davon wird
durch Spezialkonstruktionen reichlich geschluckt ;)
Peter Dannegger schrieb:> A. K. schrieb:>> Wobei man manchmal versucht ist, ausgerechnet printf zu vermeiden.>> Geht auch ohne:>> Beitrag "Formatierte Zahlenausgabe in C"
Aha, also erst propagierst du die Verwendung von printf(), statt selbst
was zu bauen, und dann präsentierst du deine selbstgebaute Alternative.
Rolf Magnus schrieb:> Aha, also erst propagierst du die Verwendung von printf(), statt selbst> was zu bauen, und dann präsentierst du deine selbstgebaute Alternative.
Daran sieht man mal, wie sich der Programmierstil mit der Zeit ändert.
Bei nem GLCD ist der printf-Overhead eh nur Peanuts.
