[Deque]

Therefore @Deque you are also wrong. :lol:

Every compiler might return a different result here, because some evaluate ++y before y++ and some do it the other way around.

It does depend on the compiler, but the fact is regardless of the compiler, for the code OP posted, you should never get a result that deviates from 8, otherwise you have a shit compiler. If regardless of the undefined behavior, you meant left to right vs. right to left. Therefore the sequence point is really irrelevant as it is meaningless here.

So... "undefined" theoretically, and "defined" in reality I suppose, since the result of 8 is guaranteed? :whistle:

Reason?

[y = 3] for ... x=(y++)+(++y):

• x = 3 -> y is incremented to 4 AFTERWARDS.
  x = 3, + (y which is 4, incremented immediately which is 5)
  therefore: x = 3 + 5 = 8
  so... x = 8

[y = 3] for ... x=(++y)+(y++):

• x = (y = 3, incremented to 4 immediately)
  therefore: x = 4
  x = 4, + (y = 4, incremented to 5 AFTERWARDS)
  therefore: x is now 4 + 4 = 8
  so... x = 8

OP's math is just wrong. But in both cases y still results in 5 after the assignment.

Let's hope Creed is using Orwells Dev-C++ and not the unmaintained original from Bloodshed.

That bloodshed one is the only one I usually think of when I hear DevC++ anywhere... It's a shame because of the existence of Orwells compiler.

I'm going to tag @Creed in this post as well as I think he should read my math above. It's essential for understanding auto-incrementing operators.

So you just take as a given that the side effect of y++ takes place before the ++y is evaluated? You can't.
For the compiler it would be right to do this:

y=3
y++ --> value of y is still 3, increment happens later
++y --> value of y is 4
x = 4 + 3 --> = 7
increment y --> value of y is 5

So, again, the behaviour is undefined, no matter how you put it.

[Deque]

Therefore @Deque you are also wrong. :lol:

Every compiler might return a different result here, because some evaluate ++y before y++ and some do it the other way around.

It does depend on the compiler, but the fact is regardless of the compiler, for the code OP posted, you should never get a result that deviates from 8, otherwise you have a shit compiler. If regardless of the undefined behavior, you meant left to right vs. right to left. Therefore the sequence point is really irrelevant as it is meaningless here.

So... "undefined" theoretically, and "defined" in reality I suppose, since the result of 8 is guaranteed? :whistle:

Reason?

[y = 3] for ... x=(y++)+(++y):

• x = 3 -> y is incremented to 4 AFTERWARDS.
  x = 3, + (y which is 4, incremented immediately which is 5)
  therefore: x = 3 + 5 = 8
  so... x = 8

[y = 3] for ... x=(++y)+(y++):

• x = (y = 3, incremented to 4 immediately)
  therefore: x = 4
  x = 4, + (y = 4, incremented to 5 AFTERWARDS)
  therefore: x is now 4 + 4 = 8
  so... x = 8

OP's math is just wrong. But in both cases y still results in 5 after the assignment.

Let's hope Creed is using Orwells Dev-C++ and not the unmaintained original from Bloodshed.

That bloodshed one is the only one I usually think of when I hear DevC++ anywhere... It's a shame because of the existence of Orwells compiler.

I'm going to tag @Creed in this post as well as I think he should read my math above. It's essential for understanding auto-incrementing operators.

So you just take as a given that the side effect of y++ takes place before the ++y is evaluated? You can't.
For the compiler it would be right to do this:

y=3
y++ --> value of y is still 3, increment happens later
++y --> value of y is 4
x = 4 + 3 --> = 7
increment y --> value of y is 5

So, again, the behaviour is undefined, no matter how you put it.

[ArkPhaze]

So you just take as a given that the side effect of y++ takes place before the ++y is evaluated? You can't.
For the compiler it would be right to do this:

y=3
y++ --> value of y is still 3, increment happens later
++y --> value of y is 4
x = 4 + 3 --> = 7
increment y --> value of y is 5

So, again, the behaviour is undefined, no matter how you put it.

Yes, in this case you can't, and so I never said it was that way. Read my edit. I only mentioned that it didn't matter which way things are evaluated, for the reasons I have shown in the later part of my post. ++y and then y++, or the other way around, you'll still end up with 8.

And you are still wrong lol. I don't care what kind of compiler you have, there's no way that this can be 7. :lol:

y++ --> value of y is still 3, increment happens later

Yes it happens later, but immediately after, so immediately after that, y = 4, NOT 3. And when ++y gets evaluated, it takes that 4, and increments it by 1 giving you an immediate 5, and NOT the 4 that you think it is. After y++ is evalutated in that expression within the line itself, the value is seen as 3, but is incremented to 4 after, in which gets further incremented to 5 by ++y.

You're both getting this wrong here... This is the way auto-incrementing operators actually work:

Code:

y=3 y++ --> value of y is still 3, increment happens later {y incremented here: y is now 4} ++y --> value of y is 4 {auto-incremented to 5 during this evaluation} x = 3 + 5 --> = 8

I'm confused on why you both think it is (or should be) 7... As you can see in my example below, the incrementing is during evaluation. Whether we use the incremented value or the original before it is incremented is also determined.

Code:

int x = 5; printf("x++: (Starting with x = %d)\n", x); printf("\tEvaluation Time: %d\n", x++); // x is incremented after the expression printf("\tAfter %d\n", x); x = 5; // x is incremented during the expression printf("\n++x: (Starting with x = %d)\n", x); printf("\tEvaluation Time: %d\n", ++x); printf("\tAfter %d\n", x);

Read my post again where I explain the math behind each way the compiler can interpret it:

[y = 3] for ... x=(y++)+(++y):

x = 3 -> y is incremented to 4 AFTERWARDS.
x = 3, + (y which is 4, incremented immediately which is 5)
therefore: x = 3 + 5 = 8
so... x = 8


[y = 3] for ... x=(++y)+(y++):

x = (y = 3, incremented to 4 immediately)
therefore: x = 4
x = 4, + (y = 4, incremented to 5 AFTERWARDS)
therefore: x is now 4 + 4 = 8
so... x = 8

These are the same:

Code:

int x = 5; printf("%d\n", ++x); x = 5; printf("%d\n", x=x+1);

They both do this:

Code:

mov eax,dword ptr [x] add eax,1 mov dword ptr [x],eax

1. So at the time variable++ happens, the value of variable immediately after this, is variable + 1.
2. The variable which was incremented is then incremented and the incremented value is taken immediately as ++x, or x+=1/x=x+1 as shown above.

This means that if variable was 3, the variable value after variable++ is 4. At the time of ++variable, that 4 is taken to 5, and that 5 is used in the expression.
Thus... value = 3 + 5, not 3 + 4.
I can prove it if you want.

[ArkPhaze]

So you just take as a given that the side effect of y++ takes place before the ++y is evaluated? You can't.
For the compiler it would be right to do this:

y=3
y++ --> value of y is still 3, increment happens later
++y --> value of y is 4
x = 4 + 3 --> = 7
increment y --> value of y is 5

So, again, the behaviour is undefined, no matter how you put it.

Yes, in this case you can't, and so I never said it was that way. Read my edit. I only mentioned that it didn't matter which way things are evaluated, for the reasons I have shown in the later part of my post. ++y and then y++, or the other way around, you'll still end up with 8.

And you are still wrong lol. I don't care what kind of compiler you have, there's no way that this can be 7. :lol:

y++ --> value of y is still 3, increment happens later

Yes it happens later, but immediately after, so immediately after that, y = 4, NOT 3. And when ++y gets evaluated, it takes that 4, and increments it by 1 giving you an immediate 5, and NOT the 4 that you think it is. After y++ is evalutated in that expression within the line itself, the value is seen as 3, but is incremented to 4 after, in which gets further incremented to 5 by ++y.

You're both getting this wrong here... This is the way auto-incrementing operators actually work:

Code:

y=3 y++ --> value of y is still 3, increment happens later {y incremented here: y is now 4} ++y --> value of y is 4 {auto-incremented to 5 during this evaluation} x = 3 + 5 --> = 8

I'm confused on why you both think it is (or should be) 7... As you can see in my example below, the incrementing is during evaluation. Whether we use the incremented value or the original before it is incremented is also determined.

Code:

int x = 5; printf("x++: (Starting with x = %d)\n", x); printf("\tEvaluation Time: %d\n", x++); // x is incremented after the expression printf("\tAfter %d\n", x); x = 5; // x is incremented during the expression printf("\n++x: (Starting with x = %d)\n", x); printf("\tEvaluation Time: %d\n", ++x); printf("\tAfter %d\n", x);

Read my post again where I explain the math behind each way the compiler can interpret it:

[y = 3] for ... x=(y++)+(++y):

x = 3 -> y is incremented to 4 AFTERWARDS.
x = 3, + (y which is 4, incremented immediately which is 5)
therefore: x = 3 + 5 = 8
so... x = 8


[y = 3] for ... x=(++y)+(y++):

x = (y = 3, incremented to 4 immediately)
therefore: x = 4
x = 4, + (y = 4, incremented to 5 AFTERWARDS)
therefore: x is now 4 + 4 = 8
so... x = 8

These are the same:

Code:

int x = 5; printf("%d\n", ++x); x = 5; printf("%d\n", x=x+1);

They both do this:

Code:

mov eax,dword ptr [x] add eax,1 mov dword ptr [x],eax

1. So at the time variable++ happens, the value of variable immediately after this, is variable + 1.
2. The variable which was incremented is then incremented and the incremented value is taken immediately as ++x, or x+=1/x=x+1 as shown above.

This means that if variable was 3, the variable value after variable++ is 4. At the time of ++variable, that 4 is taken to 5, and that 5 is used in the expression.
Thus... value = 3 + 5, not 3 + 4.
I can prove it if you want.

[Deque]

So you just take as a given that the side effect of y++ takes place before the ++y is evaluated? You can't.
For the compiler it would be right to do this:

y=3
y++ --> value of y is still 3, increment happens later
++y --> value of y is 4
x = 4 + 3 --> = 7
increment y --> value of y is 5

So, again, the behaviour is undefined, no matter how you put it.

Yes, in this case you can't, and so I never said it was that way. Read my edit. I only mentioned that it didn't matter which way things are evaluated, for the reasons I have shown in the later part of my post. ++y and then y++, or the other way around, you'll still end up with 8.

And you are still wrong lol.

y++ --> value of y is still 3, increment happens later

Yes it happens later, but immediately after, so immediately after that, y = 4, NOT 3. And when ++y gets evaluated, it takes that 4, and increments it by 1 giving you an immediate 5, and NOT the 4 that you think it is. After y++ is evalutated in that expression within the line itself, the value is seen as 3, but is incremented to 4 after, in which gets further incremented to 5 by ++y.

You still don't understand what a sequence point is. The increment is not be ensured to happen right after, only after the sequence point.

A sequence point defines any point in a computer program's execution at which it is guaranteed that all side effects of previous evaluations will have been performed, and no side effects from subsequent evaluations have yet been performed.

The side effect can take place after the sum was created, thus x can get the value 7.

I am not wrong. I told you to read it up and you didn't. It is there in the specification. Nothing to argue about.

[Deque]

So you just take as a given that the side effect of y++ takes place before the ++y is evaluated? You can't.
For the compiler it would be right to do this:

y=3
y++ --> value of y is still 3, increment happens later
++y --> value of y is 4
x = 4 + 3 --> = 7
increment y --> value of y is 5

So, again, the behaviour is undefined, no matter how you put it.

Yes, in this case you can't, and so I never said it was that way. Read my edit. I only mentioned that it didn't matter which way things are evaluated, for the reasons I have shown in the later part of my post. ++y and then y++, or the other way around, you'll still end up with 8.

And you are still wrong lol.

y++ --> value of y is still 3, increment happens later

Yes it happens later, but immediately after, so immediately after that, y = 4, NOT 3. And when ++y gets evaluated, it takes that 4, and increments it by 1 giving you an immediate 5, and NOT the 4 that you think it is. After y++ is evalutated in that expression within the line itself, the value is seen as 3, but is incremented to 4 after, in which gets further incremented to 5 by ++y.

You still don't understand what a sequence point is. The increment is not be ensured to happen right after, only after the sequence point.

A sequence point defines any point in a computer program's execution at which it is guaranteed that all side effects of previous evaluations will have been performed, and no side effects from subsequent evaluations have yet been performed.

The side effect can take place after the sum was created, thus x can get the value 7.

I am not wrong. I told you to read it up and you didn't. It is there in the specification. Nothing to argue about.

[Solixious]

To the best of my knowledge, ArkPhaze is absolutely right. The value will never end up as 7 in the given case. It will always be 8.

Code:

y=3 x=(y++)+(++y);

So it will finally be
x=3+5=8 (for left to right)
or
x=4+4=8 (for right to left)

The value of y will be 5 after the execution in any case.

[Solixious]

To the best of my knowledge, ArkPhaze is absolutely right. The value will never end up as 7 in the given case. It will always be 8.

Code:

y=3 x=(y++)+(++y);

So it will finally be
x=3+5=8 (for left to right)
or
x=4+4=8 (for right to left)

The value of y will be 5 after the execution in any case.

[Deque]

To the best of my knowledge, ArkPhaze is absolutely right. The value will never end up as 7 in the given case. It will always be 8.

Code:

y=3 x=(y++)+(++y);

So it will finally be
x=3+5=8 (for left to right)
or
x=4+4=8 (for right to left)

The value of y will be 5 after the execution in any case.

Did you even read my post? The side effect (which is the increment) of y++ can be delayed until the sequence points ends. That is after the sum was computed. You are assuming that the side effect takes place immediately, but that is by specification not ensured.

[Deque]

To the best of my knowledge, ArkPhaze is absolutely right. The value will never end up as 7 in the given case. It will always be 8.

Code:

y=3 x=(y++)+(++y);

So it will finally be
x=3+5=8 (for left to right)
or
x=4+4=8 (for right to left)

The value of y will be 5 after the execution in any case.

Did you even read my post? The side effect (which is the increment) of y++ can be delayed until the sequence points ends. That is after the sum was computed. You are assuming that the side effect takes place immediately, but that is by specification not ensured.