problem with ++i

[Gamemaster007]

Hello everyone.
I know this may be a dumb question, but I can't figure it out.
So the problem is I'm getting the output of the following program as 33.
According to me it should work like this: First the value of b is 10.
Now in b+(++b)+b, it should be as 10+(11)+11, which equals to 32. But why does the output come as 33?

#include <iostream>
using namespace std;
int main()
{
	int b=10;
	cout<<b+(++b)+b<<endl;
	return 0;
}

And does the compiler read the program from left to right?
Please help me.

[cire]

According to me it should work like this: First the value of b is 10.

According to the standard, the behavior is undefined.

[coder777]

And does the compiler read the program from left to right?

That's the point: The order of evaluation is not defined/compiler specific:

http://en.cppreference.com/w/cpp/language/eval_order

[Gamemaster007]

Thanks for that. But if the order is not defined then why the result of the following is 31?

#include <iostream>
using namespace std;
int main()
{
	int b=10;
	cout<<b+b+(++b)<<endl;
	return 0;
}

Isn't the compiler reading left to right in this case? 10+10+(11)=31

Moreover if order is not defined, then why the output is same in every run. Shouldn't it change if the order is random?

[Disch]

But if the order is not defined then why the result of the following is 31?

You misunderstand the meaning of "undefined". "Undefined" means "it can be anything." Therefore this question makes no sense.

It's like asking "if this code can produce anything, then why is it producing 31?". The answer is, it's producing 31 because it can produce anything.

Isn't the compiler reading left to right in this case? 10+10+(11)=31

Maybe. But that's not guaranteed. You could get anything.

Moreover if order is not defined, then why the output is same in every run

Because you could get anything. "Anything" includes the same number every time.

Shouldn't it change if the order is random?

It's not random... it's undefined.

'Anything' means it might be random.
Or it might be what you expect.
Or it might be what you don't expect.
Or it might cause your program to crash.

Literally anything goes. The language does not guarantee any behavior here. The behavior is undefined.


Basically... don't write code like this if you want your code to be predictable. Relying on undefined behavior is bad.

[Cubbi]

Case in point, I get the output of 33 here where you got 31.. which still means nothing.

$ cat test.cc
#include <iostream>
using namespace std;
int main()
{
        int b=10;
        cout<<b+b+(++b)<<endl;
        return 0;
}
$ CC -o test test.cc
$ ./test
33

[Gamemaster007]

Case in point, I get the output of 33 here where you got 31.. which still means nothing.

But in my compiler I get 31 every time.

[Cubbi]

Possible, but next version of the same compiler may print something else. Or a different set of optimization options may change it. Or something else. The number is just a fluke of the compiler still producing code despite violated assumptions (it assumes you never make such mistakes).

[coder777]

But in my compiler I get 31 every time.

Disch wrote:

It's not random... it's undefined.

Once the code is created it will of course always show the same result.

[Gamemaster007]

Possible, but next version of the same compiler may print something else.

I've checked the same code in C-free and Turbo c++, in both the cases answer is same.

[Disch]

Gamemaster: You're competely missing the point.

It doesn't matter what you're getting. You can literally get anything. The language does not dictate what the result should be.

You can get ANYTHING.

[Ganado]

one little question: Could doing b = b++; or the like actually crash your program (if b is just an int, not associated with an array index or anything like that)? Sure, it's "undefined", but I still feel like there is only a finite range of values that b could become, and no matter what b becomes, even if it's an overflow, that alone couldn't crash the program. Or maybe I'm wrong?

[Disch]

one little question: Could doing b = b++; or the like actually crash your program?

Realistically, it won't. But nothing in the language says it won't.

And a compiler could make your program crash on that line of code and still be 100% standards compliant.

[Ganado]

Ok thanks, I see.

[Gamemaster007]

You can get ANYTHING.

This is getting more confusing. Can you please elaborate a bit more on 'anything'. The thing I'm not understanding is why the output always gives a fixed value, when it can be anything? Why it outputs that particular value?

[Disch]

This is getting more confusing. Can you please elaborate a bit more on 'anything'.

It's really very simple... if it's confusing you are over-thinking it. But I'll try to elaborate:

C++ is a language. It has a set of "rules" which dictate how things work.

For example... the language says that if you input an expression like so: 5 + 10, it will result in the sum of those two numbers, giving you 15. This will always happen because the language says it will. It's guaranteed. It's how the language works. It's one of its rules.

There is no such guarantee for what you're doing. There's no rule. It's outside what the language says will happen. Therefore anything can happen.

The thing I'm not understanding is why the output always gives a fixed value, when it can be anything?

"Anything" means, quite literally, "any" "thing".

31 is a thing.

If I can have "any" thing... then that means I could have 31.

64 is also a thing. Therefore if I can have anything that means I could also have 64.


Just because you are getting 31 now... doesn't mean everyone always will. Someone could get something else. Anything could happen.



EDIT:

To rephrase... these are all "things":

- 31
- 64
- 32
- 30
- program crashes
- -781264687

"anything" means that any of those things can happen.

[Gamemaster007]

Thanks, Disch.
I think I'm getting your point.

Someone could get something else.

So, basically this means that the output is never fixed, right?
We cannot predict the output of that program without compiling it, and we always have to compile such programs to see the output?

[Disch]

So, basically this means that the output is never fixed, right?

Your output might be fixed, or it might not be. It's undefined.

What it means is your output is unpredictable and there is no value in trying to analyze "why" it's behaving the way it is.

We cannot predict the output of that program without compiling it

You can never predict it. It's undefined.

and we always have to compile such programs to see the output?

Yes, I guess. But the output is meaningless because it's undefined.



You are looking for patterns where there are none. Trying to make sense of code that is nonsensical.

[Gamemaster007]

Thanks everyone.
I think Disch has solved my problem.
Disch, thanks for taking your time to help me.

[Disch]

Happy to help. =)