3
#include <stdio.h>

int main()
{
  int x=100;
  x=x++;
  printf("x : %d\n",x); //prints 101
  return 0;
}

What is the reason for output 101? I think output should be 100.

Roddy
  • 66,617
  • 42
  • 165
  • 277
  • 2
    This smells like undefined behavior. – John May 14 '13 at 16:26
  • It should be 101, you are mistaken – SpacedMonkey May 14 '13 at 16:28
  • 1
    I wish all questions on SO have that many answers :) – maverik May 14 '13 at 16:30
  • It should be 101. Try "printf("x : %d\n",x++)" instead of "x=x++" if you want 100. –  May 14 '13 at 16:31
  • 1
    It *is* undefined behavior? Check accepted answer here: http://stackoverflow.com/questions/949433/could-anyone-explain-these-undefined-behaviors-i-i-i-i-i-etc – John May 14 '13 at 16:50
  • @maverik - I'd settle for one right answer rather than seven wrong ones, though. – Roddy May 14 '13 at 16:53
  • I think it should be drop-kicked into the next county. – Hot Licks May 14 '13 at 17:00
  • 1
    Can't believe this *weekly* question has got so many wrong answers. `x = x++;` This invokes **undefined behaviour** in C. The important thing to note here is that the assignment operator ( `=` ) *doesn't* introduce a sequence point. So whether the incremented value is assigned to `x` or old value of `x` is assigned to `x` can't be deduced correctly as `x` is being modified twice without an intervening sequence point in the expression `x = x++`. – P.P May 14 '13 at 17:15
  • @KingsIndian "weekly" only if you spend too much time elsewhere. Almost daily. – Daniel Fischer May 14 '13 at 17:48
  • @DanielFischer hehe... May be I am not active enough to predict the frequency of this question accurately ;-) Nice to your your shadow face :) – P.P May 14 '13 at 18:11
  • 1
    @KingsIndian - You can spend all day waiting for a language lawyer, then five come round at once ;-) SO's problem is the increasing number of bad questions make it almost impossible to find the nuggets. – Roddy May 14 '13 at 19:01

7 Answers7

6

This is Undefined Behaviour, due to Sequence Points.

Between consecutive "sequence points" an object's value can be modified only once by an expression

The end of the previous epxression x=100; is one sequence point, and the end of x=x++; is another.

Basically, your expression has no intermediate 'sequence points', yet you're modifying the value of X twice. the result of this is Undefined Behaviour: Basically, anything could happen: You could get 100, 101 or 42...

Roddy
  • 66,617
  • 42
  • 165
  • 277
  • I think you're right? I suspected it but didn't investiage. http://stackoverflow.com/questions/949433/could-anyone-explain-these-undefined-behaviors-i-i-i-i-i-etc – John May 14 '13 at 16:49
  • @John - Thanks. I've flagged this question as a duplicate. – Roddy May 14 '13 at 16:52
4

Here is what I believe you're looking for:

int main(){
    int x=100;
    printf("x : %d\n",x++); // Will print 100 and then increment x
    return 0;
}
Captain Skyhawk
  • 3,499
  • 2
  • 25
  • 39
  • But in Java, this program's output is 100. Value is assigning before increment. But why is it change here?? – Thisara Ranawaka May 14 '13 at 16:29
  • @ThisaraRanawaka C is not Java - different rules are in place here. – Reed Copsey May 14 '13 at 16:29
  • @Reed - So what's the "Rule" here, then? why *isn't* this UB? – Roddy May 14 '13 at 16:38
  • There was a comment (I don't know why author deleted it) and it said that increment goes first and then assignment (due to operators priorities). Isn't that right? – maverik May 14 '13 at 16:39
  • If this is correct, what does `x = 2 * x++;` do, and why? – Roddy May 14 '13 at 16:56
  • @Roddy: The result of `x=x++` *is* undefined - 6.5.2/2: "If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined." Both the `=` and `++` have side effects (assignment and increment, respectively), and they are not sequenced relative to each other (it's not guaranteed that the assignment happens before the increment). The result will vary based on compiler, platform, surrounding code, etc. – John Bode May 14 '13 at 17:01
  • @JohnBode - Thanks for confirming! Please vote to close before we get any more wrong answers... – Roddy May 14 '13 at 17:05
1

You're incrementing x before printing it - so this is the reason for the output 101.

You're doing the same operations as x = x; x++;

MRalwasser
  • 15,605
  • 15
  • 101
  • 147
  • 1
    But `x++;` would do the same thing. Or is `x = x++;` the same thing as `x++; x = x;` ? – John May 14 '13 at 16:28
  • @John It's more like the other way around - `x = x; x++;` - the assignment is basically "thrown away" in this case. – Reed Copsey May 14 '13 at 16:31
0

You're incrementing x after assigning it to x, effectively:

The x=x++ effectively becomes (assign x to x prior to increment) then (increment x)

This is going to give the same effect as if you were to wrote:

x = x;
++x; // Increment after the assignment

This should leave x as 101 after the x=x++; line.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • Shouldn't the lines be the other way around? Postincrement has higher precedence than assignment? – John May 14 '13 at 16:34
  • @John Yes... But the value is returned prior to the incremented value being set (hence **post**-increment), so the assignment happens prior to the increment. – Reed Copsey May 14 '13 at 16:35
0

You're incrementing the same x you're printing - here it doesn't matter whether post- or pre-incrementing.

x=x++ would produce the same result as x=++x.

If you would like to assign it another object do this:

#include<stdio.h>

int main(){
        int x=100;
        int y=x++;
        printf("y : %d\n",y); //prints 100
        printf("x : %d\n",x); //prints 101
        return 0;
}
laika
  • 1,319
  • 2
  • 10
  • 16
0

This is what is happening

#include <stdio.h>

int main()
{
  int x=100;
  x=x++; // This is original code however I have rewritten this as below 
  x=x;
  x++;
  printf("x : %d\n",x); //prints 101
  return 0;
}

as you can see

x=x++;

can be rewritten as

x=x;
x++;

hence the result no surprises ...

asio_guy
  • 3,667
  • 2
  • 19
  • 35
0

The effect is that the value of x won't change.

x++ works like this:

  1. Take a reference of the value.
  2. Allocate a new integer and store the value into it.
  3. Increment the reference.
  4. Return the temporary integer.

In C++ it would look like this:

int PostIncrement(int& x)
{
    int y = x;
    x = x + 1;
    return y;
}

The operator precedence is not lost in this way and the assignment is done after the increment.

Konstantin Dinev
  • 34,219
  • 14
  • 75
  • 100
  • 1
    The order of operations is not guaranteed. 6.2.5/3: "The grouping of operators and operands is indicated by the syntax.85) **Except as specified later, side effects and value computations of subexpressions are unsequenced.** 86)" It's possible for the assignment to be sequenced before the increment; it's also possible for the assignment to be sequenced after the increment. The result will vary from compiler to compiler (or for the same compiler with different optimization settings). – John Bode May 14 '13 at 19:12
  • @JohnBode This is correct. In most commonly used implementations the order is as I have described. – Konstantin Dinev May 14 '13 at 19:17
  • `int& x` is a syntax error in C. – Pascal Cuoq May 14 '13 at 19:34