Paul Eggert wrote:
> On 4/6/22 01:24, arn...@skeeve.com wrote:
> > Most people
> > would wonder "Why is there a bitwise and here?" and not think of it
> > as a logical and.
>
> I'm not sure I agree about the "most", as I expect most people won't
> notice or care about this level of detail. Howev
On 4/6/22 01:24, arn...@skeeve.com wrote:
Most people
would wonder "Why is there a bitwise and here?" and not think of it
as a logical and.
I'm not sure I agree about the "most", as I expect most people won't
notice or care about this level of detail. However, for people who
wonder like that,
On 4/6/22 03:28, Bernhard Voelker wrote:
Well, it was an argument to say that & eliminates a conditional execution
branch, but if both sides of the & operator have to be evaluated
They don't. Neither operand has side effects, so a compiler can evaluate
either operand and not bother to evaluate
On 4/6/22 10:24, arn...@skeeve.com wrote:
> I'll stick to my opinion that && is better here since we're doing
> logical tests; the short-circuit nature of && is less important.
_
Well, it was an argument to say that & eliminates a con
Paul Eggert wrote:
> On 4/6/22 00:04, arn...@skeeve.com wrote:
> > IMHO clear code beats saving a single branch
>
> Sure, but clarity also argues for "&" over "&&" here. Writing "f(x) &&
> f(y)" would incorrectly imply that it's important that f(y) should not
> be evaluated when f(x) is false,
On 4/6/22 00:04, arn...@skeeve.com wrote:
IMHO clear code beats saving a single branch
Sure, but clarity also argues for "&" over "&&" here. Writing "f(x) &&
f(y)" would incorrectly imply that it's important that f(y) should not
be evaluated when f(x) is false, an implication that is incorrec
> On 4/5/22 22:18, arn...@skeeve.com wrote:
> > dfa.c:1093:27: warning: use of bitwise '&' with boolean operands
> > [-Wbitwise-instead-of-logical]
Paul Eggert wrote:
> It's valid in C to use bitwise '&' on bool, and doing so here eliminates
> a conditional branch at the machine level, which
