Gast
#915952
müssen die inneren abfragen noch einmal geklammert werden? kommen ohne klammerung ein anderer vergleichswert raus als mit klammerung? if(twi_status == 0x08 | twi_status == 0x10) mfg
In diesem Fall brauchst du keine Klammern, "==" hat eine höhere Rangordnung als "|", also wird erst verglichen, dann das oder ausgeführt. Wenn du aber anfängst mehrere logische Operationen zu nutzen solltest/musst du die Blöcke entsprechend klammern.
Gast
#915960
Mussten da nich zwei Balken rein?
also z.B.
if(bla == blubb || blo = blobb) { ... }
Geht genau genommen beides, sinnvoller und deshalb üblich ist aber "||". Spätestens bei if ((b != 0) & (a / b == 1)) wird der Unterschied zwischen "&" und "&&" wichtig.
Andreas Kaiser wrote: > Spätestens bei > if ((b != 0) & (a / b == 1)) > wird der Unterschied zwischen "&" und "&&" wichtig. Nö, auch da sind "&" und "&&" praktisch äquivalent. Wichtig wird es, wenn einer der Operanten auch größer als 1 sein kann (z.B. "if (a && b)"), oder der rechte Operant einen Seiteneffekt hat.
Stefan Ernst wrote: >> if ((b != 0) & (a / b == 1)) > > Nö, auch da sind "&" und "&&" praktisch äquivalent. Interessant. Kannte ich bisher anders. Bei "&" werden beide Seiten berechnet, also wird bei b==0 seelenruhig durch 0 dividiert, was dem Programm ein jähes Ende bereiten kann. Bei "&&" ist sichergestellt, dass die rechte Seite nur berechnet wird, wenn die linke Seite zutrifft. > oder der rechte Operant einen Seiteneffekt hat. Eben. Er hat.
> Bei "&&" ist sichergestellt, dass > die rechte Seite nur berechnet wird, wenn die linke Seite zutrifft. Ja, das meinte ich mit "oder der rechte Operant einen Seiteneffekt hat". Aber das mit der Division durch Null habe ich übersehen. (peinlich) Du hast natürlich Recht!
Gast
#916001
Aus dem Gesetzbuch: "Unlike the bitwise binary & operator, the && operator guarantees left-to-right evaluation; there is a sequence point after the evaluation of the first operand. If the first operand compares equal to 0, the second operand is not evaluated." Auch wenn der rechte Operand keinen Seiteneffekt hat, ist das && meist vorzuziehen, weil es fast immer Rechenzeit einspart. Außerdem dient es der Lesbarkeit, wenn man durch die Wahl des Operators ausdrückt, ob eine logische oder eine bitweise Operation gemacht wird.
@ yalu: Ja, das ist klar. Es ging ja auch nur darum, dass ein Programm nicht immer sofort fehlerhaft ist, wenn der "falsche" Operator benutzt wird.
yalu wrote: > Auch wenn der rechte Operand keinen Seiteneffekt hat, ist das && meist > vorzuziehen, weil es fast immer Rechenzeit einspart. Bei Controllern stimmt das. Bei PC-Prozessoren kann das auch andersrum ausgehen, je nachdem wie gut sich die bei "&&" verwendeten Sprungbefehle vorhersagen lassen.
Gast
#916028
Da sehe ich gerade, dass der GCC, wenn möglich, das & wie ein && behandelt, es sei denn, der rechte Operand hat einen definierten Seiteneffekt. Da a/b keinen (für b!=0) oder einen undefinierten (für b==0) Seiteneffekt hat, wird sogar hier die &&-Variante genommen.
Gast
#916240
Ich kann aus meiner Erfahrung nur empfehlen, möglichst immer Klammern zu schreiben. Dies dient der besseren Lesbarkeit / Verständnis des Codes und verhindert damit komische Fehler, die im Nachhinein fast nicht mehr gefunden werden können, da sie rasch übersehen werden.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.