So /g/ my dev group has been debating this for the last 20 or so min.
if you have:
x=1;
x=x++;
return x;
what will be returned, 1 or 2.
we've tested it in a few compilers, C# says 1, C++ says 2, except one compiler that says it's using GCC says it returns 1, but I tested in a compiler using GCC and it returned 2.
Which is right and why?
I made a strawpoll, in case you guys can't decide.
http://strawpoll.me/6272397
>>51874668
Undefined behaviour.
Asking this is as pointless as asking what number rand() will return.
>>51874678
rand() is psuedo-random though so if you know the seed you can exactly predict what the next value will be
>>51874678
it clearly is in C++ though.
if using inc. operator is undefined behavior, how can you trust it in any of your code?
>>51874678
the operator is clearly defined in documentation though. It should be 2. that is a retarded way of doing it, but it isn't undefined.
>>51874678
This anon is right, its undefined behavior
(though x = ++x; would be well defined in c++11 or later)
>>51874668
It's 2 - but it doesn't really matter.
clearly x will be returned.
>having mutable variables
kek
>>51874668
Depends how the compiler compiles it and what the standard says (if anything).
Logically with the postfix op what you are doing is assigning x to itself then incrementing it (i.e. x = x; x += 1;) , so the result should be 2.
>>51874668
>C#
>x++ – postfix increment. Returns the value of x and then updates the storage location with the value of x that is one greater (typically adds the integer 1).
>The result of x++ or x-- is the value of x before the operation, whereas the result of ++x or --x is the value of x after the operation. In either case, x itself has the same value after the operation.
>++ has higher precedence that =
so with
>x = x++;
>evaluate right-hand side "x++"
>postfix, so return value of x which is 1
>right-hand side is done with return value of 1.
>so evaluate x++, x = 2. But
>evaluate x = right-hand side return value which is 1.
x = 1
>move to next line
also https://stackoverflow(.)com/questions/226002/whats-the-difference-between-x-x-vs-x
>>51874668
>So /g/ my dev group has been debating this for the last 20 or so min.
Your dev group is retarded.
>>51874668
it's undefined behavior in c++, just don't use it
>>51874668
i++ increments i but returns the value before incrementation. Therefore, it should return 1.
This is the very core concept of it at an assembly level, '++' essentially means "increment it while you're there". It stems from specific CPU instructions which allow to do two operations in one.
GCC is wrong on this one.
>>51874668
>what will be returned, 1 or 2.
I dunno for C# but for C++ and C it is undefined and will end up with nasal demons flying out your nose.
>>51876506
>GCC is wrong on this one.
Have you filed a bug report?
>>51876526
You can fill bug reports about dogshit to complain that it smells?
>>51876506
>GCC is wrong on this one.
Actually, it's not. It might invoke Emacs and make it solve Towers of Hanoi if it wanted to.
It's unspecified behaviour.
>>51876563
>It's unspecified behaviour.
That's wrong.
>>51874668
in C:
= is an expression which assign to the variable at its left the value of everything at its right.
x++ is another expression which FIRST evaluates the variable, THEN increments it. As opposed to ++x, which first increments then evaluates.
Therefore a sane compiler would do this, assign the value of x before incrementing it to x (x=1), then increment it.
2 is the value that should be returned.
>>51876574
>assign the value of x
It should assign the value of the expression, not x. That's the issue here.
>>51876573
Yeah, it is undefined.
>>51876596
This: http://programmers.stackexchange.com/a/153449
>>51876615
Fuck off with your stackexchange.
I have the standard at hands.
>>51876592
Exactly, the value of the expression x++ is x. That is the difference between ++x and x++.
++x is increment first, evaluate then.
x++ is evaluate first, increment then.
For example with:x = 1;
y = x++;
at the end y will be equal to 1, while x = 2.x = 1;
y = ++x;
Instead will result in x = 2 and y = 2.
>>51876626
So does the stackexchange answer. Also quote them.
>>51876596
I get that it's undefined. But I meant "wrong" as in "who the fuck releases something that has undefined behavior?"
It only screams "I don't know what the fuck I'm coding".
Jave returns 1, in fact IDEA itself "warns" me that "The value changed at x++ is never used"
>>51876655
This isn't about coding, it's about language design.
>>51876664
>Jave
Java*
>>51876666 (waste of repeating digits)
My mistake, I thought the language design resulted in both a coding effort for the compiler and the ability to use said compiler to compile your code.
This goes both ways, it shouldn't be undefined at any level.
>>51876655
>But I meant "wrong" as in "who the fuck releases something that has undefined behavior?"
Do you even understand what undefined means?
>>51876698
>it shouldn't be undefined at any level.
But it is, how can you make assumptions about sequence points that are true for all architectures and platforms?
The reason why it isn't undefined in C#, Java and other higher-level programming languages is because they do a shittonne of boilerplate to avoid that stuff (such as running in a virtual machine or an interpreter).
>>51876708
I do.
Do you understand the dozens of meanings of "wrong"?
>>51876698
C is a low-level language, essentially a portable assembler. By making some expressions (dereferencing NULL, signed integer overflow) undefined, compilers can generate the fastest code for whatever platform, since they don't have to generate checks for e.g. NULL dereferencing when the platform doesn't do this in hardware.
C is all about being fast, not about easy to write or secure. Hence a buttload of security holes.
Recommended reading: https://homes.cs.washington.edu/~akcheung/papers/apsys12.html
>>51876725
The issue is clear, the logic is sound.
Only it is not properly implemented.
>>51876753
>Only it is not properly implemented.
It is, because the standard clearly doesn't define it is illegal in the language (hence no compiler error). However, if you bothered to enable compiler warnings you would see that GCC actually catches a lot of undefined behaviours.
Anyway, relying on the compiler/interpreter to tell you whether your code is well-defined or ill-defined is absolutely pants on head retarded.
>>51876742
See >>51876725 and my above answer
>>51874668
>can't believe this actually returns 1 in C#
>test it myself
>it does
>>51876776
>the standard clearly doesn't define it is illegal in the language
Which leads to undefined behavior. Which shouldn't happen. I don't want the compiler to decide the outcome of my code. It is "wrong".
It's not because the compiler needs vague concepts to optimize its efficiency that the accuracy should go out the window.
If I was to release something with "undefined" behavior I'd get fired on the spot.
x++ is a defining statement in itself.
You declare x as 1. Then you see x to itself and then add one to x after you set it to 1.
It will, or rather should, return 2 in all cases.
>>51876877
Is it even possible not to release an undefined burger at McDonalds?
>>51874678
This anon is correct it could return anything, depending on what the compiler wants to do.
Undefined behaviour really should be a compile-time error, but it isn't.
>>51874678
>>51874668
>undefined behavior
>returned 2
You're lucky that's all it did. It could have deleted your hard drive.
>>51874668
"Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored."
= does not constitute a sequence point, therefore x = x++ will try to modify x twice in the same sequence point, thus undefined behavior.
>>51874668
it should be 2
you are saying x = x, then you increment x by 1
>>51874668
Should be 2, but if your compiler is stupid and optimizes it wrongly I can see it returning 1.
what should happen is
x <- 1
x <- x
increment x
return x
x = 1;
y = x++;
There you go, y == 1.
>mfw C# is right
>>51874668
unlike some are saying it is not really undefined behavior since both operations are actually well defined
x++ first returns x then increments 1 to x
x=a assigns the value of a to x
so x=x++ does
return x
x=x+1
x=x
the last return should be x+1
