Kann man in einer switch Struktur break in eine if-Bedingung setzen? Sieht etwas "komisch" aus und mag ungewöhnlich sein, aber geht das rein techisch?
Ja kann man. Aber mann sollte es nicht mit allzu vielen Verschachtelungen übertreiben, da der Quelltext dabei schnell unübersichtlich wird.
Stefanus F. schrieb: > Ja kann man. Aber mann sollte es nicht mit allzu vielen > Verschachtelungen übertreiben, da der Quelltext dabei schnell > unübersichtlich wird. Ja ich mach das ungern, aber es bietet sich aktuell an. Danke für die schnelle Antwort.
Absichtlich durchfallende cases sind immer mal wieder gut für ne temporäre Hirnverknotung beim Leser des Codes, ich würd noch nen knappen Kommentar dazu schreiben um sich prophylaktisch für die Unannehmlichkeiten zu entschuldigen und zu erklären warum das an der Stelle passieren muss. Abgesehen davon ist es OK.
:
Bearbeitet durch User
switchbreak schrieb: > Kann man ... aber geht das rein techisch? was ist bei dir "rein technisch"? Syntax oder Semantik? wenn die Syntax (die Grammatik) nicht stimmt, dann wird dich der Compiler drauf aufmerksam machen. Der Satz "Fahrrad Hund der das isst" ist z.B. syntaktisch fehlerhaft. Wenn die Semantik (die Bedeutung) nicht stimmt, dann wirst du es am Ergebnis merken. Der Satz "Der Hund isst das Fahrrad" ist syntaktisch korrekt, aber die Semantik ist etwas seltsam
Bernd K. schrieb: > temporäre Hirnverknotung hab ich heute den ganzen Tag :) Daher ja die Frage Vielleicht sollte ich mal Schluss machen. So sieht das aus. HEUTE fällt mir nichts besseres ein.
1 | // SM: LED-Blinksequenz ausgeben
|
2 | switch (iErrStatus) { |
3 | case 1: // Aufruf via Timer |
4 | if (IsZS(SM_BIT_TM)) // Im Troublemodus keine Blinksequenz |
5 | {break;} |
6 | case 2: // Manueller Aufruf |
7 | DiISR(); // ISR sperren |
8 | SM.ErrOutAktiv = 1; // Fehlerausgabe ist aktiv |
9 | SM_PrintByte(iErrNr, 7, 2, ErrOutputReadyE); // Fehler per Blinksequenz ausgeben |
10 | EnISR(); // ISR erlauben |
11 | break; |
12 | default: /*nichts*/ |
13 | break; |
14 | } // Ende LED-Blinksequenz ausgeben |
switchbreak schrieb: >> temporäre Hirnverknotung > > hab ich heute den ganzen Tag :) Der Klassiker ist:
1 | case 1: |
2 | if (IsZS(SM_BIT_TM)) |
3 | {break;} |
4 | // fall thru
|
5 | case 2: |
Echte Hirnverknotung: ;-)
1 | case 1: |
2 | if (!IsZS(SM_BIT_TM)) { |
3 | case 2: |
4 | ...
|
5 | }
|
6 | break: |
:
Bearbeitet durch User
A. K. schrieb: > Echte Hirnverknotung: ;-) >
1 | > case 1: |
2 | > if (!IsZS(SM_BIT_TM)) { |
3 | > case 2: |
4 | > ... |
5 | > } |
6 | > break: |
7 | >
|
Jetzt hast du noch mal geändert. Wenn ich bei Fsll 2 bin, höre ich freiwillig auf ;)
Geht noch schöner:
1 | case 1: |
2 | if (!IsZS(SM_BIT_TM)) { |
3 | case 2: |
4 | ...
|
5 | break:
|
6 | }
|
7 | case 3: |
Bernd K. schrieb: > Absichtlich durchfallende cases sind immer mal wieder gut für ne > temporäre Hirnverknotung beim Leser des Codes, ich würd noch nen knappen > Kommentar dazu schreiben Ich würde vorschlagen einen der (pseudo) Standard-Marker dafür zu verwenden: GCC Attribut:
1 | __attribute__ ((fallthrough)); |
GCC und Clang Marker-Kommentar, eine Reihe von Schreibvariationen von Fall Through, wie:
1 | // fall through
|
2 | // FALLTHROUGH
|
3 | // FALLTHRU
|
4 | // fall-through
|
- blöderweise noch von einer Compiler-Option abhängig. C++17 Standard:
1 | [[fallthrough]]; |
GCC C++ Erweiterung:
1 | [[gnu::fallthrough]]; |
Welchen jetzt genau? Ach, das Schöne an Standards ist doch, dass es so viele davon gibt. > sich prophylaktisch für die > Unannehmlichkeiten zu entschuldigen und zu erklären warum das an der > Stelle passieren muss. Warum? Es gibt nur einen Grund: Damit der Code macht was er soll.
Peter D. schrieb:
1 | case 1: |
2 | if (!IsZS(SM_BIT_TM)) { |
3 | case 2: |
4 | ...
|
5 | break:
|
6 | }
|
7 | case 3: |
Wer macht denn sowas?!? :-) :-) :-) switch/case ohne break lässt sich auch sehr gut für loop unrolling mit dynamischer Schleifenlänge verwenden.
:
Bearbeitet durch User
Einen Switch mit nur zwei relevanten Cases würde ich durch ein If-Konstrukt ausdrücken. Dann entfällt in diesem Fall sogar eine Verschachtelungsebene:
1 | if(iErrStatus==1 && !IsZS(SM_BIT_TM) || iErrStatus==2) { |
2 | DiISR(); |
3 | SM.ErrOutAktiv = 1; |
4 | SM_PrintByte(iErrNr, 7, 2, ErrOutputReadyE); |
5 | EnISR(); |
6 | }
|
Yalu X. schrieb: > Einen Switch mit nur zwei relevanten Cases würde ich durch ein > If-Konstrukt ausdrücken. Kommt drau an. Wenn man für ein Kunstmuseum programmiert , sieht deas doch auch schick aus
1 | switch (i) { |
2 | case 1: // Aufruf via Timer |
3 | default: // Manueller Aufruf |
4 | if (1) { |
5 | case 3: |
6 | break; |
7 | }
|
8 | |
9 | break; |
10 | }
|
PS:
switchbreak schrieb: >
1 | > for(byte n=0; n<10; n++) { |
2 | > if(n < 6) }; // Exit bei n=6 |
3 | >
|
Wieso ist das syntaktisch OK?
1 | stefan@stefanspc:~/Downloads$ cat test.c |
2 | #define byte unsigned char
|
3 | |
4 | int main(int argc, char** argv) |
5 | {
|
6 | for(byte n=0; n<10; n++) |
7 | {
|
8 | if(n < 6) // Exit bei n=6 |
9 | };
|
10 | }
|
11 | stefan@stefanspc:~/Downloads$ gcc test.c |
12 | test.c: In function ‘main’: |
13 | test.c:8:5: error: expected expression before ‘}’ token |
14 | }; |
15 | ^
|
Was soll denn da den "Exit" bewirken? Vermutlich hast du ein "break;" vergessen und die Bedingung falsch geschrieben, richtig?
1 | #define byte unsigned char
|
2 | |
3 | int main(int argc, char** argv) |
4 | {
|
5 | for(byte n=0; n<10; n++) |
6 | {
|
7 | if(n == 6) break; // Exit bei n=6 |
8 | };
|
9 | }
|
So ist es compilierbar.
Random .. schrieb: > Peter D. schrieb: case 1: > if (!IsZS(SM_BIT_TM)) { > case 2: > ... > break: > } > case 3: > > Wer macht denn sowas?!? :-) :-) :-) z.B. der Herr Adam Dunkel mit seinen Protothreads. https://de.wikipedia.org/wiki/Protothread Und natürlich noch viele mehr. (z.B. meiner seiner)
Arduino Fanboy D. schrieb: > z.B. der Herr Adam Dunkel mit seinen Protothreads. Oha, erinnere mich nicht daran. Ich brauchte Tage, bis ich verinnerlicht hatte, welche Folgen seine Protothreads und die darauf aufbauenden Protosockets für die Programmierung haben. Auf den ersten Blick hat er sich da was ganz tolles ausgedacht, was den Code gut lesbar macht. Aber er hat dabei auch einen grossen Haufen neuer Fallstricke eingeführt. Ich kann von Protothreads nur abraten. Meiner Meinung nach hat er damit die Programmiersprache missbraucht. Für nicht eingeweihte gibt es hier eine kurze Beschreibung auf deutsch: http://stefanfrings.de/net_io/protosockets.html
Stefanus F. schrieb: > Auf den ersten Blick hat er sich da was ganz tolles ausgedacht, was den > Code gut lesbar macht. Das stimmt. Damit kann besonders ein Anfänger sehr einfach Multitasking programmieren, was deutlich besser ist, als sich mit tausenden Delays die Echtzeit zu zerschießen. Die automatische Case-Generierung ist recht clever. Die Fallsticke halten sich im Rahmen bei kleinen Programmen. In der 4ma wird man dafür natürlich gesteinigt.
Stefanus F. schrieb: > Oha, erinnere mich nicht daran. Ich brauchte Tage, bis ich verinnerlicht > hatte, welche Folgen seine Protothreads und die darauf aufbauenden > Protosockets für die Programmierung haben. Solche Methoden genialer Minimalistik funktionieren deutlich besser, wenn man sie sich selbst ausgedacht hat. ;-)
A. K. schrieb: > case 1: > if (!IsZS(SM_BIT_TM)) { > case 2: > ... > } > break: Markus F. schrieb: > https://de.wikipedia.org/wiki/Duff% hier wieder der Beweis, dass C einfach nur sch... ist. Anstatt die Sprache zu verbessern, werden Krückenkonstrukte generiert und die Gemeinde geilt sich daran auf. Sorry, geht gar nicht. :-<<<
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.