I have found cases in real life where both sides of the expression were really cheap, so it shaved off a nanosecond or two to avoid the branch and to use the unconditional &
instead of &&
. (These were extremely high-performance math utilities, though; I would almost never use this in other code, and I wouldn’t have done it anyway without exhaustive benchmarking to prove it was better.)
(To give specific examples, x > 0
is going to be super cheap and side-effect-free. Why bother risking a branch misprediction to avoid a test that’s going to be so cheap anyway? Sure, since it’s a boolean
the end result is going to be used in a branch anyway, but if (x >= 0 && x <= 10)
involves two branches, and if (x >= 0 & x <= 10)
involves only one.)