This question already has answers here:
Undefined behavior and sequence points
(5 answers)
Closed 7 years ago.
Lets take simple C++ code like:
int main(){
int a = 0;
while(a<3) {
a=a++;
std::cout<<a<<std::endl;
}
}
This code built using Visual Studio 2015 print 1, 2, 3 when g++ 5.2.0 goes into an infinite loop and print only zeros.
According to C++ Operator Precedence assignment operator (=) has a lower priority then a post-incrementation. It would suggest that first zero is assignment to variable 'a', after that 'a' is incremented, so after first iteration a = 1. So result obtained from VS 2015 is right. Why GCC produce different output?
Your pogram is invalid (Undefined behavior) thus the compiler can generate anything.
The problem is your assigning to a single variable more than once in a statement (something to do with sequence points).
a=a++;
Thus should be:
a++;
Related
This question already has answers here:
How do we explain the result of the expression (++x)+(++x)+(++x)? [duplicate]
(5 answers)
Closed 3 years ago.
int a = 10;
a = a++;
cout << a<<" ";
a++;
cout << a;
In microsoft Visual its output is 11 12
And in other compilers (like codechef and codeforces) its output is 10 11
This question's Output was asked in some mcq paper and the correct answer is 10 11 but can any1 also explain how
a = a++;
++a;
cout<<a;
produces output of 11 does a = a++ does't do anything?
a = a++; is not a correct statement due to lack of sequence point or being unsequenced(C++11).
undefined behavior - there are no restrictions on the behavior of the program. Examples of undefined behavior are memory accesses outside of array bounds, signed integer overflow, null pointer dereference, more than one modifications of the same scalar in an expression without any intermediate sequence point (until C++11)that are unsequenced (since C++11), access to an object through a pointer of a different type, etc. Compilers are not required to diagnose undefined behavior (although many simple situations are diagnosed), and the compiled program is not required to do anything meaningful.
https://en.cppreference.com/w/cpp/language/ub
This question already has answers here:
Undefined behavior and sequence points
(5 answers)
Closed 4 years ago.
Whats happening x after executing the code below;
int x = 10;
x += x--;
I'm expecting result 19 (adding x to x and then decrease x by 1) but result 20. How does it works behind the curtains? Thank your for your answers.
The behavior in this case was undefined before C++17, see e.g., https://en.cppreference.com/w/cpp/language/eval_order#Undefined_behavior , so if your compiler does not conform to it, it is no use testing or trying to understand it: it will depend on implementation, or even version of the compiler.
If your compiler conforms to C++17, it is guaranteed that in a simple or compound assignment (= or e.g. +=, respectively) all of the side effects of right hand side will be dealt with before evaluating the left hand side.
In your case, x-- is evaluated to be 10 accompanied by setting x=9 as its side effect, then the computer will add 10 to x=9 resulting in x=19.
Thanks to Michał for his correction, which I incorporated into the answer.
Having an older c++ might probably not do the job as the behaviour is literally defined to be undefined, by the older standard. (Thanks to #LightnessRacesinOrbit)
If you just try out an online compiler which will have the latest version, it works just fine and the result is 19 as you expected (x+=x-- is the same as x= x+x--. This means for getting the new "x", it has to sum the old "x"+the old "x" -1. So it will do x+(x--), which is x=10+(9).
Try it out here:
with:
#include <iostream>
using namespace std;
int main()
{
int x = 10;
x += x--;
cout<<x<<endl;
}
This question already has answers here:
Undefined behavior and sequence points
(5 answers)
What's the reason for letting the semantics of a=a++ be undefined?
(8 answers)
Closed 5 years ago.
I have been running this code at different compilers. At Microsft VS. it prints 1, but at gcc, it prints 0. What is the result according to the standard c++. I don't if there is standardization for this piece of code as well.
int a=0;
a=a++;
cout << a<< endl;
a=a++ is undefined behavior. Not only is there no standard definition for what will happen, it isn't even guaranteed to always do the same thing between different runs.
It could print 0 now, 1 the next time, and crash your program on the third attempt.
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Undefined behavior and sequence points
(5 answers)
Closed 7 years ago.
The codes in this Post-increment within a self-assignment, testing with C++.
However I get different result between VS2013 and GCC4.8.4
int cc = 42;
cc = cc++;
cout << cc << endl;
The result of VS2013 is 43, but the result of GCC is 42. It confuse me...
Which result is correct?
This is textbook undefined behavior. The compiler can do whatever the hell it wants to. By the language spec, it is allowed to halt and catch fire, should it so choose; be glad they just did something vaguely related to the nonsense you fed them.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Undefined behavior and sequence points
#include< iostream.h>
int main()
{
int i=7,j=i;
j=(i++,++i,j++*i);
cout <<j;
return 0;
}
What will be the output of the C++ code?
It's my homework that my professor gave me.
It sometimes helps to convince people who don't believe this is undefined by actually compiling the program with several compilers and observing the results:
After fixing the iostream.h error,
g++ 4.5.2 prints 64
CLang++ 2.8 prints 63
Sun C++ 5.8 prints 63
MSVC 2010 prints 64
(oh, and, re-written to use C I/O, the original K&R C compiler on Unix 7 prints 63)
[Edited to account for OP's question changing edit]:
It's undefined as to what the output will be.
There are the following errors in the code:
#include <iostream.h> should be #include <iostream>,
j is uninitialized so the value of j++*i isn't known - OK, this got fixed in the edit,
Besides, the assignment itself is improper. The convoluted line can be rewritten as:
i++;
++i;
j = j++ * i;
And the last part is invalid for the reasons described here:
Undefined behavior and sequence points
Essentially, you're incrementing i by 2, multiplying it by the original value of j, and adding one.
In the end, j=64
j = ((7+2)*7) + 1 = (9*7)+1 = 63+1 = 64
At least that's what my Visual Studio 2010 compiler does with it.