why should ++(i++) be not well-defined?
Hello,
You say in your reply that ++(i++) shoould not be well-defined. I don't
think that's right. please see below.
On 09/26/2010 07:46 PM, Armen Tsirunyan wrote:
On Sep 26, 10:00 pm, "Johannes Schaub (litb)"<schaub-johan...@web.de>
wrote:
Armen Tsirunyan wrote:
Please help me, I just can't understand this.
Clause 1.9 Paragraph 15 (n3092) says:
Except where noted, evaluations of operands of individual operators
and of subexpressions of individual
expressions are unsequenced. [ Note: In an expression that is
evaluated more than once during the execution
of a program, unsequenced and indeterminately sequenced evaluations of
its subexpressions need not be
performed consistently in different evaluations. ?end note ] The value
computations of the operands of an
operator are sequenced before the value computation of the result of
the operator. If a side effect on a scalar
object is unsequenced relative to either another side effect on the
same scalar object or a value computation
using the value of the same scalar object, the behavior is undefined.
[ Example:
void f(int, int);
void g(int i, int* v) {
i = v[i++]; // the behavior is undefined
i = 7, i++, i++; // i becomes 9
i = i++ + 1; // the behavior is undefined
i = i + 1; // the value of i is incremented
f(i = -1, i = -1); // the behavior is undefined
}
?end example ]
let's consider i = v[i++]. the side effect of i being incremented by 1
is SEQUENCED before the side effect of i being assigned v[i++],
because "The value computations of the operands of an operator are
sequenced before the value computation of the result of the operator".
So how come is this undefined behavior?
Because value computations do not include side effects. So you have two
unsequenced side effects in your snippet (the increment and assignment).
Moreover you have a value computation on i (left i) that is unsequenced
relative to a side effect on i (the right "i++").
If you write this as "i = v[++i]", which is equivalent to "i = *(v + (i = i
+ 1))" you will not have two unsequenced side effects anymore, because the
assignment in "i = i + 1" is sequenced before the assignment in "i = *(...".
BUT you still have the same value computation be unsequenced to the same
side effect as in your snippet. So for both the pre and postfix version you
have undefined behavior.
If I may quote you from another thread :)
++i = 0; // defined by c++0x, undefined by C++03
++ ++i; // defined by c++0x, undefined by C++03
i = ++i; // defined by c++0x, undefined by C++03
Please disregard the last one. That's still undefined in C++0x it seems.
Value computation of the left i is not sequenced relative to the side effect
of "++i".
i = ++i; whether or not this is defined depends pretty much on what a
value computation means.
Also, is
(++i)++;
defined?
I guess not, am I right?
To my knowledge the above ++(i++) expression is absolutely well-defined
since the brackets enforce uniqueness.
C++ as any language guarantees that subexpressions of an expression are
evaluated before the expression itself is evaulated. Ambiguities only
arise in the order of the evaluations of subexpressions, which are
unsequenced (=unspecified) in C++ for good reason. But here the bracket
inforces uniqueness. The brackets can be understood as a unary operator.
We would get the following syntax tree:
pre-increment
|
brackets
|
post-increment
|
i
Where is the ambiguity? I don't see any, albeit the expression is ugly
of course. Even if we take out the brackets the expression would be
unique, since right increments have higher priority than left increments.
Cheers,
Andreas