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.

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!

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.

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.

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.