Ich dachte, dass sowas wie
1 | if(bytevar & 0x1F == 0x1F) |
selbstverständlich ist. Aber nein, man muss es so schreiben:
1 | if((bytevar & 0x1F) == 0x1F) |
Ja,die Operratorreihenfolge in C gibt aber auch nichts anderes vor... https://en.cppreference.com/w/c/language/operator_precedence
Georg M. schrieb: > Ich dachte ... Das Beste daran: man muss dabei zum Glück gar nichts denken, sondern einfach nur das Handbuch zur verwendeten Sprache durchlesen. Da sind noch mehr solcher überraschenden Tricks versteckt...
:
Bearbeitet durch Moderator
Angehängte Dateien:
-
warnung.png
13 KB
und Georg M. schrieb: > selbstverständlich weist dich der Compiler mit einer Warnmeldung exakt darauf hin.
Lothar M. schrieb: > Da sind noch mehr solcher überraschenden Tricks versteckt... Selbst wenn man die richtige Reihenfolge einhält empfiehlt es sich bei so etwas immer zu Klammern, diese kosten nichts und stellen das gewünschte Verhalten sicher. Spätestens wenn der Werksstudent loslegt merkt man wie sinnvoll so etwas ist...
Εrnst B. schrieb: > weist dich der Compiler mit einer Warnmeldung exakt darauf hin. Gibt es denn eine sinnvolle Anwendung für die gewählte Priorität? Gerne auch indirekt? Sonst ist es einfach ein Fehler der Pilgrims (àh Gründerväter).
> Gibt es denn eine sinnvolle Anwendung für die gewählte Priorität?
Sollte sich wohl ähnlich verhalten wie && und || - bei denen erwartet
man diese Priorität bzg ==, <= und >=.1 | if (a==b && c==d) ... |
2 | if (a==b & c==d) ... |
foobar schrieb: > Sollte sich wohl ähnlich verhalten wie && und || - bei denen erwartet > man diese Priorität bzg ==, <= und >=. Dachte ich auch erst, dann verworfen und gefragt (weil ja nicht "boolsch") und nun plausibel im Lichte des Parallelthreads: Damit wäre && ohne Kurzschluss und Klammer möglich: !a() & b()==0 & c()!=0 | geht ja sowieso :-)
Ich klammere immer, dann muss ich nicht denken. Lieber eine Klammer zu viel, als eine zu wenig. Sonst ist man später stundenlang am Debuggen.
> Ich klammere immer, dann muss ich nicht denken.
Dann fehlen da aber welche ...
PittyJ schrieb: > Lieber eine Klammer zu viel, als eine zu wenig. SCNR: lieber zwei Klammern zu viel als zwei zu wenig. Mit nur einer Klammer bekommst du eine Fehlermeldung ... 😀 Aber mit dem was du meintest pflichte ich dir bei. Wenn man sich nicht sicher ist, geht es schneller mit einem extra Klammerpaar als in der Referenz nachzuschauen.
Wo ist das Problem? Wenn Du
1 | std::byte bytevar{}; |
2 | if(bytevar & 0x1F == 0x1F) { |
3 | }
|
schreibst gibst es eine ganz klare Fehlermeldung, wenn Du
1 | uint8_t bytevar{}; |
2 | if(bytevar & 0x1F == 0x1F) { |
3 | }
|
gibt es zumindest eine aussagekräftige Warnung. Und: warum gehst Du eigentlich davon aus, dass `&` eine höhere Präzedenz hat als `==` ?
Die aus heutiger Sicht unlogische Rangfolge hat historische Gründe. Hier ist die Erklärung vom Vater von C persönlich: https://www.lysator.liu.se/c/dmr-on-or.html
Wilhelm M. schrieb: > Und: warum gehst Du eigentlich davon aus, dass `&` eine höhere Präzedenz > hat als `==` ? Aus dem gesunden Menschenverstand.
Georg M. schrieb: > Aus dem gesunden Menschenverstand. Errare humanum est. Und wenn eine unglückliche Wahl einmal zur Quasi-Standard wird, ist es zu spät. Wobei der Spruch früher länger war als heute. ;-) "Irren ist menschlich, aber auf Irrtümern zu bestehen ist teuflisch."
:
Bearbeitet durch User
Georg M. schrieb: > Wilhelm M. schrieb: >> Und: warum gehst Du eigentlich davon aus, dass `&` eine höhere >> Präzedenz hat als `==` ? > > Aus dem gesunden Menschenverstand. Den gibts nicht bei C (und nicht nur da). Allerdings ist es wenigstens komplett dokumentiert. Wer programmiert, ohne das Handbuch zu lesen, der ist ohnehin schlecht beraten. Es gibt schließlich auch Programmiersprachen, bei denen nicht mal Punkt- vor Strichrechnung gilt. Z.B. APL oder SmallTalk.
Axel S. schrieb: > Wer programmiert, ohne das Handbuch zu lesen, > der ist ohnehin schlecht beraten. Richtige Männer brauchen keine Handbücher.
Andreas B. schrieb: > Richtige Männer brauchen keine Handbücher. Die schreiben nämlich grundsätzlich alle Ausdrücke so in Klammern dass keine Missverständnisse aufkommen (können). So einfach ist das. Lothar M. schrieb: > Das Beste daran: man muss dabei zum Glück gar nichts denken
erklehr behr schrieb: > Die schreiben nämlich grundsätzlich alle Ausdrücke so in > Klammern dass keine Missverständnisse aufkommen (können). Am besten verwendet man doppelte Klammern, damit sie auch ganz sicher nicht übersehen werden:
1 | ((x=((((((a*b))-c))+1)))); |
;-)
erklehr behr schrieb: > Andreas B. schrieb: > >> Richtige Männer brauchen keine Handbücher. > > Die schreiben nämlich grundsätzlich alle Ausdrücke so in > Klammern dass keine Missverständnisse aufkommen (können). Richtige Männer brauchen keine überflüssigen Verzierungen wie Klammern. LG, Sebastian
Zuviel Klammern können auch schaden:
1 | if ((a=b) && (b==c)) { |
2 | // ^
|
3 | // Tippfehler
|
4 | // vs.
|
5 | if (a=b && b==c) { |
Ohne die Zusatz-Klammern warnt der Compiler, dass an der Stelle
eventuell keine Zuweisung gemeint sein könnte.
>>> warning: suggest parentheses around assignment used as truth value
Mit den Extra-Klammern unterdrückt man die Warnung.
Εrnst B. schrieb: > Zuviel Klammern können auch schaden: > >
1 | > if ((a=b) && (b==c)) { |
2 | > // ^ |
3 | > // Tippfehler |
4 | > // vs. |
5 | > if (a=b && b==c) { |
6 | >
|
Da hilft vor allem, die (möglichst alle) lokalen Variable 'const' zu deklarieren.
HildeK schrieb: > SCNR: lieber zwei Klammern zu viel als zwei zu wenig. > Mit nur einer Klammer bekommst du eine Fehlermeldung ... 😀 :) Der Professor führt eine Rechnung an der Tafel aus und stellt irgendwann fest: 'Mist, Vorzeichenfehler'. Er geht die Zeilen rückwärts noch einmal durch, finden einen Fehler, korrigiert ihn und sagt: 'So, 'Vorzeichenfehler beseitigt.' Anmerkung eines Studenten: 'Die Zahl der Vorzeichenfehler ist nunmehr gerade.'
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.