Is a && b && c defined by the language to mean (a && b) && c or a && (b && c)?
Wow, Jerry was quick. To beef up the question: does it actually matter? Would there be an observable difference between a && b && c being interpreted as (a && b) && c or a && (b && c)?
§5.14/1: "The && operator groups left-to-right. [...] Unlike &, && guarantees left-to-right evaluation: the second operand is not evaluated if the first operand is false."
As to when or how it matters: I'm not sure it really does for built-in types. It's possible, however, to overload it in a way that would make it matter. For example:
#include <iostream>
class A;
class M {
int x;
public:
M(int x) : x(x) {}
M &operator&&(M const &r);
M &operator&&(A const &r);
friend class A;
};
class A {
int x;
public:
A(int x) : x(x) {}
A &operator&&(M const &r);
A &operator&&(A const &r);
operator int() { return x;}
friend class M;
};
M & M::operator&&(M const &r) {
x *= r.x;
return *this;
}
M & M::operator&&(A const &r) {
x *= r.x;
return *this;
}
A &A::operator&&(M const &r) {
x += r.x;
return *this;
}
A &A::operator&&(A const &r) {
x += r.x;
return *this;
}
int main() {
A a(2), b(3);
M c(4);
std::cout << ((a && b) && c) << "\n";
std::cout << (a && (b && c)) << "\n";
}
Result:
9
16
Caveat: this only shows how it can be made to matter. I'm not particularly recommending that anybody do so, only showing that if you want to badly enough, you can create a situation in which it makes a difference.
In fact it is very important that the expression is computed from left to right. This is used to have short-circuit in some expressions. Here is a case where it does matter:
vector<vector<int> > a;
if (!a.empty() && !a[0].empty() && a[0].back() == 3)
I bet you write similar statements few times a day. And if associativity was not defined you would be in huge trouble.
The && and || operators short-circuit: if the operand on the left determines the result of the overall expression, the operand on the right will not even be evaluated.
Therefore, a mathematician would describe them as left-associative, e.g.
a && b && c ⇔ (a && b) && c, because to a mathematician that means a and b are considered first. For pedagogical purposes, though, it might be useful to write a && (b && c) instead, to emphasize that neither b nor c will be evaluated if a is false.
Parentheses in C only change evaluation order when they override precedence. Both a && (b && c)
and (a && b) && c will be evaluated as a first, then b, then c. Similarly, the evaluation order of both
a + (b + c) and (a + b) + c is unspecified. Contrast a + (b * c) versus (a + b) * c, where the compiler is still free to evaluate a, b, and c in any order, but the parentheses determine whether the multiplication or the addition happens first. Also contrast FORTRAN, where in at least some cases parenthesized expressions must be evaluated first.
If a && b is false, then the && c portion is never tested. So yes, it does matter (at least in that you need to have your operations ordered from left to right). && is an associative operation by nature.
Associative Property
Within an expression containing two or more occurrences in a row of the same associative operator, the order in which the operations are performed does not matter as long as the sequence of the operands is not changed. That is, rearranging the parentheses in such an expression will not change its value.
So it doesn't matter (logically) if you write it as a && (b && c) or (a && b) && c. Both are equivalent. But you cannot change the order of the operations (e.g a && c && b is not equivalent to a && b && c).
