![]() |
|
Logic Unknown - help needed - Printable Version +- Sinisterly (https://sinister.li) +-- Forum: Coding (https://sinister.li/Forum-Coding) +--- Forum: C, C++, & Obj-C (https://sinister.li/Forum-C-C-Obj-C) +--- Thread: Logic Unknown - help needed (/Thread-Logic-Unknown-help-needed) |
RE: Logic Unknown - help needed - Creed_mybb_import11544 - 04-18-2013 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 .. RE: Logic Unknown - help needed - Creed_mybb_import11544 - 04-18-2013 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 .. RE: Logic Unknown - help needed - Psycho_Coder - 04-18-2013 (04-18-2013, 12:21 PM)Creed Wrote: 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++ Don't use Dev C++ , use Visual C++ or Orwell's Dev C++ , RE: Logic Unknown - help needed - Psycho_Coder - 04-18-2013 (04-18-2013, 12:21 PM)Creed Wrote: 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++ Don't use Dev C++ , use Visual C++ or Orwell's Dev C++ , RE: Logic Unknown - help needed - Deque - 04-18-2013 (04-18-2013, 01:04 PM)Psycho_Coder Wrote: Don't use Dev C++ To back this up: http://clicktobegin.net/programming/why-you-shouldnt-use-dev-c/ RE: Logic Unknown - help needed - Deque - 04-18-2013 (04-18-2013, 01:04 PM)Psycho_Coder Wrote: Don't use Dev C++ To back this up: http://clicktobegin.net/programming/why-you-shouldnt-use-dev-c/ RE: Logic Unknown - help needed - Psycho_Coder - 04-18-2013 (04-18-2013, 01:20 PM)Deque Wrote:(04-18-2013, 01:04 PM)Psycho_Coder Wrote: Don't use Dev C++ Thank you for the link , I will give it a look . RE: Logic Unknown - help needed - Psycho_Coder - 04-18-2013 (04-18-2013, 01:20 PM)Deque Wrote:(04-18-2013, 01:04 PM)Psycho_Coder Wrote: Don't use Dev C++ Thank you for the link , I will give it a look . RE: Logic Unknown - help needed - ArkPhaze - 04-18-2013 (04-18-2013, 07:56 AM)Deque Wrote:(04-18-2013, 06:50 AM)ArkPhaze Wrote: 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: Deque Wrote: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):
[y = 3] for ... x=(++y)+(y++):
OP's math is just wrong. But in both cases y still results in 5 after the assignment. Deque Wrote: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.
RE: Logic Unknown - help needed - ArkPhaze - 04-18-2013 (04-18-2013, 07:56 AM)Deque Wrote:(04-18-2013, 06:50 AM)ArkPhaze Wrote: 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: Deque Wrote: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):
[y = 3] for ... x=(++y)+(y++):
OP's math is just wrong. But in both cases y still results in 5 after the assignment. Deque Wrote: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.
|