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;
}
Related
This question already has answers here:
Why are these constructs using pre and post-increment undefined behavior?
(14 answers)
Closed 21 days ago.
#include<iostream>
#include<conio.h>
using namespace std;
int main()
{
int y,**p,*pt;
int x=5;
pt=&x;
p=&pt;
y=**p + ++(**p);
cout<<*pt<<" "<<**p<<" "<<x<<" "<<y;
getch();
return(0);
}
output generated 6 6 6 11, why not 6 6 6 12 kindly guide on execution step.
Here my doubt is **p is pointing to x only which is incremented by second operand ++(**p). so value of y should be 12.
This is classic undefined behaviour! There is no guarantee in the C++ standard about the order of evaluation of the operands of the + operator in y=**p + ++(**p).
I tested your code in MSVC and clang-cl and I get the output: 6 6 6 12 - which suggests (as you expect) that ++(**p) is evaluated first. However, on your compiler, it seems that the LHS is evaluated first.
From the cppreference site linked in the comments by Scheff:
Order of evaluation of any part of any expression, including order of
evaluation of function arguments is unspecified (with some exceptions
listed below). The compiler can evaluate operands and other
subexpressions in any order, and may choose another order when the
same expression is evaluated again. There is no concept of
left-to-right or right-to-left evaluation in C++….
PS: Interestingly, changing to y = ++(**p) + **p; also gives 6 6 6 12 as the output.
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 months ago.
Improve this question
Giving this code:
#include <iostream>
#include <cmath>
using namespace std;
int main() {
int k, x;
while(k > x-3) {
k--;
// cout << "x = " << x << "\n";
}
x++, k--;
int aux = abs(k-x);
cout << aux;
}
When we run it, it always pops up a constant x (x = 50) and the absolute value between the integer k and the x is always 5. Can you please explain me why and how does this works?
With the constraint of "k is greater than x", this piece of code here
while(k > x-3) {
k--;
// cout << "x = " << x << "\n";
}
Will decrease k to be 3 less than x.
The next line, x++, k++; increases them both by 1, but it doesn't change the result. k is still 3 smaller than x.
k-x is -3 and abs(k-x) is 3, hence why the program always prints 3. Assuming, of course, that both k and x are initialized and that k is bigger than x. The program as it is posted with k and x uninitialized exhibits undefined behavior, so there's no guarantee on what is going to happen. Also, as Aconcagua points out, if x is smaller than INT_MIN + 3, that also leads to undefined behavior.
I really think you should try two arbitrary numbers.
For example , imagine we are using k= 10 & x=8.
Your loop will look like:
While(10>5) 10-1=9 ... and so on, until K is not greater than (X-3).
You will get k=5, and x is the same value,8.
After the while loop you decrement k, and increment x, so k=4 and x=9.
Abs(k-x) = 5.
If you want the more theoretical explanation, the loop will grant that the difference between your two variables is 3, the X will be greater than K.
As after the loop you decrement K and increment X , the diference between them will ALWAYS be 5.
Matthieu and πάντα ῥεῖ are correct: Ths is classic undefined behavior. (One rationale for making it undefined and not simply unspecified or implementation defined is that some architectures have flags for uninitialized registers and would trap.) A compiler is actually free to compile it to an empty program: Reading an uninitialized variable can result in anything — and nothing is a subset of anything. All subsequent code after the undefined behavior is "tainted" by the preceding error and can be omitted. Note that different architectures and different compilers, possibly even different C standard libs (with the same compiler!) may give different results; even a different compiler flag (concerning optimization or function call conventions) may change this undefined behavior.
(The rest of this answer applies to the version of the question where the line after the loop read x++, k++; (instead of k-- as it is now).)
But you have encountered a consistent behavior, and the question is why it is consistent. The first assumption is that the compiler does not simply generate code to output "5", (which it could, legitimately) but actually "naively" generates machine code that corresponds to the C statements. We'll reason along the statements.
Then the behavior indicates that the memory locations where x and k reside are containing values which make k > x -3 false right away. (Otherwise, k would be decremented until the difference is 3, not 5).
If the condition is false, the variable difference will not change; from that we can conclude that it was 5 from the start with x-k == 5. If you omit the abs(), the output should be -5.
The reason the variables have these consistent intial values may be connected to things the operating system or C runtime environment do at program startup, like initializing the standard streams. Try using printf instead of cout and see if the result changes.
This question already has answers here:
Undefined behavior and sequence points
(5 answers)
Closed 6 years ago.
I have a friend who is getting different output than I do for the following program:
int main() {
int x = 20, y = 35;
x = y++ + x++;
y = ++y + ++x;
printf("%d%d", x, y);
return 0;
}
I am using Ubuntu, and have tried using gcc and clang. I get 5693 from both.
My friend is using Visual Studio 2015, and gets 5794.
The answer I get (5693) makes most sense to me, since:
the first line sets x = x + y (which is x = 20+35 = 55) (note: x was incremented, but assigned over top of, so doesn't matter)
y was incremented and is therefore 36
next line increments both, adds the result and sets it as y (which is y = 37 + 56 = 93)
which would be 56 and 93, so the output is 5693
I could see the VS answer making sense if the post-increment happened after the assignment. Is there some spec that makes one of these answers more right than the other? Is it just ambiguous? Should we fire anyone who writes code like this, making the ambiguity irrelevant?
Note: Initially, we only tried with gcc, however clang gives this warning:
coatedmoose#ubuntu:~/playground$ clang++ strange.cpp
strange.cpp:8:16: warning: multiple unsequenced modifications to 'x' [-Wunsequenced]
x = y++ + x++;
~ ^
1 warning generated.
The Clang warning is alluding to a clause in the standard, C++11 and later, that makes it undefined behaviour to execute two unsequenced modifications to the same scalar object. (In earlier versions of the standard the rule was different although similar in spirit.)
So the answer is that the spec makes all possible answers equally valid, including the program crashing; it is indeed inherently ambiguous.
By the way, Visual C++ actually does have somewhat consistent and logical behaviour in such cases, even though the standard does not require it: it performs all pre-increments first, then does arithmetic operations and assignments, and then finally performs all post-increments before moving on to the next statement. If you trace through the code you've given, you'll see that Visual C++'s answer is what you would expect from this procedure.
This question already has answers here:
Undefined behavior and sequence points
(5 answers)
Closed 8 years ago.
1.macros has always been difficult.
2.Below is the code and output is 125 and 7....Please elaborate the working
#define mul(x) (x++ * ++x * x++)
#include<iostream.h>
void main()
{
int a=4,j;
j=mul(a);
cout<<j<<endl;
cout<<a<<endl;
}
Your program results in undefined behaviour. j could be anything.
Read more here: Undefined behavior and sequence points
What I believe is happening is this.
Set a to 4.
mul is called and a is passed in.
The second multiplication (++x) has the prefix incrementer, so x (a) is increased by 1. a is now 5.
The multiplication now happens. Since the first and last have the postfix incrementer, nothing happens until after the multiplication happens. So we have 5 * 5 * 5 = 125.
Since the multiplication is done now, the postfix incrementers happen which makes x (a) 6 and then 7.
j then equals 125.
???
Profit!
EDIT:
This is explaining the behavior that he is experiencing. I understand that this won't happen in every case.
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.