[Creed_mybb_import11544]

okay ...so its all about the compilers how they execute the code ... thanks a lot @Deque and @Psycho_Coder .. the wikipedia and the Stackoverflow links make it very clear .. and yes i am using bloodshed's Dev C++
thanks ..

[Creed_mybb_import11544]

okay ...so its all about the compilers how they execute the code ... thanks a lot @Deque and @Psycho_Coder .. the wikipedia and the Stackoverflow links make it very clear .. and yes i am using bloodshed's Dev C++
thanks ..

[Psycho_Coder]

okay ...so its all about the compilers how they execute the code ... thanks a lot @Deque and @Psycho_Coder .. the wikipedia and the Stackoverflow links make it very clear .. and yes i am using bloodshed's Dev C++
thanks ..

Don't use Dev C++ , use Visual C++ or Orwell's Dev C++ ,

[Psycho_Coder]

okay ...so its all about the compilers how they execute the code ... thanks a lot @Deque and @Psycho_Coder .. the wikipedia and the Stackoverflow links make it very clear .. and yes i am using bloodshed's Dev C++
thanks ..

Don't use Dev C++ , use Visual C++ or Orwell's Dev C++ ,

[Deque]

Don't use Dev C++

To back this up: http://clicktobegin.net/programming/why-...use-dev-c/

[Deque]

Don't use Dev C++

To back this up: http://clicktobegin.net/programming/why-...use-dev-c/

[Psycho_Coder]

Don't use Dev C++

To back this up: http://clicktobegin.net/programming/why-...use-dev-c/

Thank you for the link , I will give it a look .

[Psycho_Coder]

Don't use Dev C++

To back this up: http://clicktobegin.net/programming/why-...use-dev-c/

Thank you for the link , I will give it a look .

[ArkPhaze]

Code:

int x,y=3;
x=(y++)+(++y);
printf("%d",x);

This is really just basic stuff...

First, y starts off with 3 (it's the important one to pay attention to in this code), but first it's important to know the difference between ++? and ?++.

When we do y++ and add ++y this is what happens:

1. We take y's current value as the first number
2. increment y by 1
3. Take that last value of y which was 3 before it got incremented to 4, and add it to the incremented value of y, which is 4 incremented to 5 immediately

Here's what that would look like:

Code:

x=3+5;

You could get 7 by doing this if you were getting 8...

Code:

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

Why in the world are you using DevC++ though?

You are wrong, ArkPhaze. The behaviour is not defined by the C standard. Every compiler might return a different result here, because some evaluate ++y before y++ and some do it the other way around.
You should read about sequence points too. And maybe this question at stackoverflow: http://stackoverflow.com/questions/41763...nce-points

At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place. (§1.9/7)

This is violated, if you do: x=(y++)+(++y);

Why in the world are you using DevC++ though?

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

His compiler whispered that the result was 8 though :whistle: I was simply explaining the way it was probably being read. The only way you could get a result of 8 would be if y++ was evaluated first, as I mentioned. So his old (and very shitty bloodshed DevC++) compiler is reading left to right, but I don't see how I was wrong for explaining that... However! In the case of standardby tradition, to have this avoided, it would be easy to write an even more procedural approach with disregard to being fancy to avoid linecount (lol), for doing exactly what you want to do, instead of trying to trick the compiler by putting it all on one line.

edit: Ahh, I read the code wrong. I guess that's the result of trying to interpret it manually at 1AM in the morning through notepad. I was trying to write a more "defined" version (for both cases) after you brought that up the second time, and I caught where I went wrong.

Still, I don't see how it would be tough to test...

edit: See I get a result of 9 from the following code, so I know that my compiler reads left to right:

Code:

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

The opposite result would be 104, in which case you know your compiler reads right to left. Simple way I came up with for testing.

@Creed - There's no way you can test that way, and your assumption is wrong because right to left, left to right, the result you would be getting is always going to be 8 for the code that you have. You should never get 7 with that code ever. And if you do, then your compiler has a serious problem, as it's not properly adding.

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.

[ArkPhaze]

Code:

int x,y=3;
x=(y++)+(++y);
printf("%d",x);

This is really just basic stuff...

First, y starts off with 3 (it's the important one to pay attention to in this code), but first it's important to know the difference between ++? and ?++.

When we do y++ and add ++y this is what happens:

1. We take y's current value as the first number
2. increment y by 1
3. Take that last value of y which was 3 before it got incremented to 4, and add it to the incremented value of y, which is 4 incremented to 5 immediately

Here's what that would look like:

Code:

x=3+5;

You could get 7 by doing this if you were getting 8...

Code:

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

Why in the world are you using DevC++ though?

You are wrong, ArkPhaze. The behaviour is not defined by the C standard. Every compiler might return a different result here, because some evaluate ++y before y++ and some do it the other way around.
You should read about sequence points too. And maybe this question at stackoverflow: http://stackoverflow.com/questions/41763...nce-points

At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place. (§1.9/7)

This is violated, if you do: x=(y++)+(++y);

Why in the world are you using DevC++ though?

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

His compiler whispered that the result was 8 though :whistle: I was simply explaining the way it was probably being read. The only way you could get a result of 8 would be if y++ was evaluated first, as I mentioned. So his old (and very shitty bloodshed DevC++) compiler is reading left to right, but I don't see how I was wrong for explaining that... However! In the case of standardby tradition, to have this avoided, it would be easy to write an even more procedural approach with disregard to being fancy to avoid linecount (lol), for doing exactly what you want to do, instead of trying to trick the compiler by putting it all on one line.

edit: Ahh, I read the code wrong. I guess that's the result of trying to interpret it manually at 1AM in the morning through notepad. I was trying to write a more "defined" version (for both cases) after you brought that up the second time, and I caught where I went wrong.

Still, I don't see how it would be tough to test...

edit: See I get a result of 9 from the following code, so I know that my compiler reads left to right:

Code:

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

The opposite result would be 104, in which case you know your compiler reads right to left. Simple way I came up with for testing.

@Creed - There's no way you can test that way, and your assumption is wrong because right to left, left to right, the result you would be getting is always going to be 8 for the code that you have. You should never get 7 with that code ever. And if you do, then your compiler has a serious problem, as it's not properly adding.

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.