incrementing an integer paradox

[RayLopez99]

// consider:

int i = 0
i = i++;

int j = 0;
j++;

int k = 0;
k = k + 1;

//

Why is it the first output for i gives zero, while the next two, for j
and k, give 1?

Why ask why?

That's just the way it is...

RL

 

[Göran Andersson]

// consider:

int i = 0
i = i++;

int j = 0;
j++;

int k = 0;
k = k + 1;

//

Why is it the first output for i gives zero, while the next two, for j
and k, give 1?

Why ask why?

That's just the way it is...

RL

That's very simple. The return value of the ++ operator is the value
before the variable was incremented.

The code:

i = i++;

gives the same result as:

int temp = i;
i = i + 1;
i = temp;

 

[Jeff Johnson]

// consider:

int i = 0
i = i++;

int j = 0;
j++;

int k = 0;
k = k + 1;

//

Why is it the first output for i gives zero, while the next two, for j
and k, give 1?

Because of the way prefix and postfix operators work and the right-to-left
order of processing. Here's what's happening for i:

1) Since this is a postfix operator, the value of i is taken before the ++
is performed. This value is 0. It is held somewhere.

2) The right-hand side continues to be executed and the postfix operation is
performed. i now contains 1.

3) FINALLY, the assignment to i on the left-hand side is made, using the
stored value (0) from step 1. This is why i is 0 in the end.

 

[Michael Starberg]

RayLopez99 wrote:

The code:

i = i++;

gives the same result as:

int temp = i;
i = i + 1;
i = temp;

No it doesn't Göran. Had too much Glögg over holiday? =)

It does this:

int temp = i;
i = temp;
temp = temp + 1;

That is why the result is zero.

Regards
- Michael Starberg

 

[gerry]

just to jump into the fray , I should think it would be something closer to
:

int temp = i;
i = i +1;
i = temp;

 

[Michael Starberg]

just to jump into the fray , I should think it would be something closer
to :

int temp = i;
i = i +1;
i = temp;

oh, indeed

Regards
- Michael Starberg

 

[Jeff Johnson]

just to jump into the fray , I should think it would be something closer
to :

int temp = i;
i = i +1;
i = temp;

Which is EXACTLY what Göran wrote! I'm pretty sure Michael's answer is
wrong: the increment on the RHS will take place before the assignment to the
LHS, and it is definitely i that is being incremented, not the "temp," it's
just that i is then immediately set to a different value ("temp").

 

[gerry]

oops

Which is EXACTLY what Göran wrote! I'm pretty sure Michael's answer is
wrong: the increment on the RHS will take place before the assignment to
the LHS, and it is definitely i that is being incremented, not the "temp,"
it's just that i is then immediately set to a different value ("temp").

 

[Göran Andersson]

No it doesn't Göran. Had too much Glögg over holiday? =)

It does this:

int temp = i;
i = temp;
temp = temp + 1;

That is why the result is zero.

Regards
- Michael Starberg

No, you are describing what this code does:

(i = i) + 1;

 

[Tim Roberts]

// consider:

int i = 0
i = i++;

int j = 0;
j++;

int k = 0;
k = k + 1;

//

Why is it the first output for i gives zero, while the next two, for j
and k, give 1?

I do not know the situation for C#, but it is worth pointing out that your
first sample is not valid C code. More specifically, the behavior of the
statement is undefined. The compiler could set i to 0, or set i to 1, or
set i to 499 and crash the app. Any of those would be perfectly valid
results.

 

[Göran Andersson]

Why is it invalid? I thought the semantics of C (and C#) was as follows:

i++ is an expression which evaluates to the (current) value of i, but as a side effect, causes i to be incremented afterward.

So in i = i++ the operations are:
(1) Evaluate i++ giving 0.
(2) Increment i.
(3) Assign to i the value that was obtained in (1).

Am I mistaken?

Yes, you are mistaken. The semantics in C and C# are not the same. In C#
the expression on the right will be performed before the assignment, but
in C the assignment is not a "secure point", so it's not defined if the
assignment or the increment occurs first.

As the statement is undefined, it's not even defined that it has to
produce either of those two results. It could produce any result without
breaking the standard.

Can someone point us to the C language definition?

Here's what the comp.lang.c FAQ says about it:

http://c-faq.com/expr/ieqiplusplus.html