4 ms·
The relative priorities of && vs ||, or & vs |, match the traditional precedence in logical expressions: "and" binds more tightly than "or", just as * binds mor
by not2b 3y ago
The relative priorities of && vs ||, or & vs |, match the traditional precedence in logical expressions: "and" binds more tightly than "or", just as * binds more tightly than + ("and" is equivalent to * for one-bit values, and "or" is addition modulo 2). So I think that they got this correct.
However, the precedence of & vs &&, or & vs ||, etc is a source of problems.
- Denvercoder9 3y ago> However, the precedence of & vs &&, or & vs ||, etc is a source of problems. Do you have any examples of this? In my experience you almost always want the bitwise operators to have a higher precedence than the logical operators, as using the result of logical operators as a bitmask makes little sense. Consider e.g. `A & B && C & D`, which currently is equivalent to `(A & B) && (C & D)`, but with reversed precedence would be equivalent to the almost nonsensical `A & (B && C) & D`. Now, the precedence of == with respect to & and | is actually problematic (as Ritchie admits as well). Having `A == B | C` interpreted as `(A == B) | C` is almost never desirable. For extra annoyance, the shift operators do have higher precedence than comparison, so `A == B << C` does what you usually want (`A == (B << C)`).
- not2b 3y agoIt usually comes up if the user intended to write && and writes & at one point in an expression, the different precedence can produce an unexpected result. But gcc and clang have warnings for that.
- Denvercoder9 3y agoThe only operators with precedence between & and && are ^ and |, though. In e.g. the expression from the sibling comment, `a & b == c`, writing & or && doesn't make any difference (aside from short-circuiting). I guess it's an issue if you write & instead of && in an expression that also involves a bitwise-OR (or | instead of || in an expression that also involves logical-AND), but that seems quite rare. I expect that reversing the precedence of the bitwise and logical operators would create problems a lot more often.
- ynik 3y ago& vs && doesn't feel like a problem to me. & vs == is the real problem: `(val & MASK) == CONSTANT` needs parentheses due to this mistake. `a & (b == c)` essentially almost never makes sense (== gives you a boolean, and when dealing with booleans you can use && instead), yet that it what you get by default if omitting the parentheses.
- not2b 3y agoYes, the latter issue comes up when the user meant to say && but types & instead.
- nneonneo 3y agoThe example given in the post is that & used to be the only conjunction operator, before && was added. Therefore, it was normal to write “if (a==b & c==d)”. While this is definitely not used anymore, the historical context is useful for explaining why the precedence of & is so low.
- User23 3y agoOff the top of my head I can’t think of anything that should bind more weakly than the equivalence.
- teo_zero 3y agoReally? Do you think equivalence should be weaker than && and || so that you would write if ((a==0) && (b==0)) instead of if (a==0 && b==0)
- deleted 3y ago[deleted]
- User23 3y agoI think equivalence and equality should different operators. 2==x should be a syntax error, because equivalence compares Boolean expressions (and possibly their extensions depending on the language). Equality should be checked with the customary sign, and assignment should be some visually asymmetric operator like :=. As you say, Equality should bind more strongly than the Boolean typed operations, including conjunction, disjunction, and equivalence. Tangentially, I wonder if if (a+b == 0) generates more efficient code in presently popular languages with that syntax.
- c2occnw 3y ago> match the traditional precedence in logical expressions arithmetic expressions?