It's guaranteed by the C and C++ standards, and for the ternary operator (x ? y : z) as well. http://en.wikipedia.org/wiki/Short-circuit_evaluation

hmm...well I almost got convinced that I should use above technique a lot until I read that.

Short-circuiting can lead to errors in branch prediction on modern processors, and dramatically reduce performance (a notable example is highly optimized ray with axis aligned box intersection code in ray tracing)[clarification needed]. Some compilers can detect such cases and emit faster code, but it is not always possible due to possible violations of the C standard. Highly optimized code should use other ways for doing this (like manual usage of assembly code).[citation needed]

Citation needed indeed. It's logically equivalent to an if/else and the compiler probably knows that.

That sounds like someone may be thinking about the conditional-move and family on some CPU instructions. That could certainly interact with the branch prediction, but there's nothing about the operators that necessitate it.

Sure, it may be that some compilers do generate different code and some runs faster than others, but that's just not the kind of thing you can tell without benchmarking those very specific conditions. If you're writing a ray tracer, you're probably are going to want to hand-tune the assembly but that's not the common case of C and C++ programming.

I don't think that comment is intended for the scenario listed above, it's more appropriate for SIMD code where it's often better to calculate both execution paths and then select (using vsel/vec_sel(a,b) on Altivec or the equivalent bitwise logical operations on SSE) the value using masks generated by comparison operators, if only because the penalties associated with performing a branch on a SIMD result are often significant.