preincrement and assignment

Started by
26 comments, last by MaulingMonkey 14 years, 11 months ago
Let's talk about this snippet of code:

int i = 0;
i = ++i;
Observations (please correct me if I'm wrong): 1. Since we are writing to i twice without a sequence point in between, the behavior is undefined. So the following discussion is just for amusement. 2. We don't know wether the left operand or the right operand of the assignment is evaluated first. 3. If the right operand is evaluated first, this means that the VALUE of the expression "++i" is 1, but that does not imply that the value of i is 1 at that point, because we don't know exactly when ++ takes EFFECT. 4. If we further assume that the side effect of assignment happens before the side effect of increment, we get 2 as a value of i at the semicolon. Nobody I have discussed this issue with seems to agree with me on point 4. Share your thoughts :)
Advertisement
No matter how you look at it I'm not sure how you can get a i == 2 after doing a ++ on a i of 0...
Unless you mean it assigns a ++'ed i to i then does the ++ on the already assigned i, but it's hardly logical
Quote:Original post by Rewdew
but it's hardly logical

But is it... plausible?
the ++ operator when placed before the variable does not return a value unless the variable itself has been increased by one. So I dont think saying the expression's value is anything if it isnt already evaluated, and by that point the registers already have the pointer to i waiting for the right side of the assignment to be caclulated.

im not sure if that answered the question/statement, maybe I missed something lol
++i is evaluated first and returns a reference to itself which it is assigned to...?

i dont see what the problem is?
Quote:Original post by DevFred
But is it... plausible?

Not really no
According to the standard, this is undefined, as you have pointed out correctly.

However, other than with the similar example of post-increment, I think that the result is nevertheless well-defined here, since the compiler really has no other choice but to evaluate ++i first.
If it was decided to do the assignment first, it would still have to evaluate the increment before that, as it needs the value to assign, which it can't get without evaluating the pre-increment first.
Quote:Original post by DevFred
4. If we further assume that the side effect of assignment happens before the side effect of increment, we get 2 as a value of i at the semicolon.

Nobody I have discussed this issue with seems to agree with me on point 4. Share your thoughts :)

Using your code as a starting point and producing this sample program:
int main(int, char **) {  int i = 0;  i = ++i;  std::cout << i;  return 0;}

MSVC 2008 spits out 1 for the value of i. So given the fact that a compiler has disagreed with your logic, I think you're going to have to live with the fact that 4 doesn't hold true.
Quote:Original post by SiCrane
So given the fact that a compiler has disagreed with your logic, I think you're going to have to live with the fact that 4 doesn't hold true.

So the output of one compiler defines undefined behavior? Hmmm... :)
No, the existence of one counterexample is enough to prove a statement false.

This topic is closed to new replies.

Advertisement