Well, the reason for & and && not the one that evaluates the right side, but the other not.
& is a bitwise operator , which does the bitwise AND of two values. It returns a value.
Theoretically, if all the bits of the left side are 0 (as is the case with false ), the right side does not have to be evaluated. I guess this is a design decision that is being evaluated in each case. In simple cases, this is faster than checking if the left side is 0.
&& is a conditional logical operator that takes two logical values ​​and returns a logical value (i.e. true if and only if both sides are true ).
The same applies here, if the left side is false , we do not need to check the correct side. Here it was decided to skip the assessment of the right side in this case.
And to answer your last question (when you want to evaluate RHS if LHS failed), there are some scenarios where this might be good. However, in any case, you can prevent these situations (see jocelyn answer to make sure that both expressions are evaluated) without losing readability. In fact, I think the jocelyn path is more readable than if (exprA() & exprB()) { ... } .
Personally, I never use & unless I really need bitwise I.
source share