7 ms·
It's part of the language [1] [2] > Builtin operators && and || perform short-circuit evaluation (do not evaluate the second operand if the result is known aft
by bicolao 4y ago
It's part of the language [1] [2]
> Builtin operators && and || perform short-circuit evaluation (do not evaluate the second operand if the result is known after evaluating the first), but overloaded operators behave like regular function calls and always evaluate both
[1] https://en.cppreference.com/w/cpp/language/operator_logical https://en.cppreference.com/w/cpp/language/operator_logical
[2] https://en.wikipedia.org/wiki/Short-circuit_evaluation https://en.wikipedia.org/wiki/Short-circuit_evaluation
- tialaramex 4y agoNote that (CPP reference will also tell you) this only applies to the built-in operator. If the operator has been overloaded which is easy to write in C++, then too bad - the overload doesn't short circuit. I think if you can't figure out a way to preserve the short-circuit feature then having a way to overload this operator in your language is stupid. It is, I would say, unsurprising to me that C++ did it anyway. EtA:: It feels like in say Rust you could pull this off as a trait LogicalAnd implemented on a type Foo, with a method that takes two parameters of type FnOnce() -> Foo , and then the compiler turns (some_complicated_thing && different_expression) where both of the sub-expressions are of type Foo into something like: { let a = (|| some_complicated_thing); let b = (|| different_expression); LogicalAnd::logical_and(a, b) } To deliver the expected short-circuiting behaviour in your implementation of the logical_and method, you just don't execute b unless you're going to care about the result.