int i=2; printf("%d %d",++i,++i); how can o/p be 4 4 with any order of evaluation

[abhi17]

this expression has undefined o/p but how could it give 4 4 pls suggest any possible mechanism by which 4 4 is produced

[Banfa]

It's undefined behaviour, anything can happen.

However with the post and pre increment and decrement operators no guarantee is provided about when the increment or decrement is done. Only about what value will be used for the expression of the operator.

i.e. ++i guarantees that the value will be the value produced by adding 1 to i but does not guarantee when exactly i will be assigned this value.


In your expression the compiler could have quite simply evaluated both ++ operators before putting anything on the stack for the function call. But as you an I have said this operation is undefined speculation is pointless.

[Vaibhav Joshi]

as per my view..the o/p should be 3 and 4...why u getting 4 4

[weaknessforcats]

Read Banfa's post again.

When you change the value of the same variable more than once in a statement, the results are indeterminate.

Seeing a display of 3 and 4 requires an assumption. Maybe there's a compiler that agrees with you, and then, maybe not.

[santechselva]

hi,
the output is 3 2.i don't know how you are supposed to get 4 4 .

regards,
santosh

[Dheeraj Joshi]

Please read posts from Banfa and weaknessforcats. The behavior varies from compiler to compiler.

Regards
Dheeraj Joshi

[Banfa]

Vaibhav Joshi: as per my view..the o/p should be 3 and 4...why u getting 4 4

santechselva: the output is 3 2.i don't know how you are supposed to get 4 4 .

OK I have said this already but I will say it again.

The output is undefined behaviour, that is the compiler is free to do anything it wants and is free to create a program that does anything including but not limited to

• Program halts with no error
• Program appears to operate as expected
• Program formats hard disk
• Program sends all your personal data to the CIA
• Demons fly out of your nose

Relying on any particular output of code like this is at best foolhardy and at worst going to result in a very non-working program.

Trying to guess what the output will be is pointless, avoid writing code that exhibits this behaviour.

[Dheeraj Joshi]

Program sends all your personal data to the CIA
Demons fly out of your nose

Really? lol.

Regards
Dheeraj Joshi

[Banfa]

Really? lol.

Well the standard does not prohibit it :D

C++ Standard
1.3.12 undefined behavior [defns.undefined]
behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this
International Standard imposes no requirements. Undefined behavior may also be expected when this
International Standard omits the description of any explicit definition of behavior.

[Dheeraj Joshi]

Ha ha ha. I am laughing out loud.

Regards
Dheeraj Joshi

[donbock]

Here is a warning I gave awhile back concerning invoking undefined behavior. It mirrors what Banfa said above.

You may think you have figured out how your particular compiler handles a particular kind of undefined behavior ... but you're wrong. Even if your program does the same thing a thousand times in a row, there is no assurance that it will behave the same way the next time you run it. And there is certainly no assurance it will behave the same way after you upgrade to the next version of the same compiler from the same vendor.

[raviroshan]

Here the answer will b 4 4 only,
Actually the syntax will be evaluated from right to left and the values are stored in i.

1) ++i = 2+1 =3
2) ++i = 3+1 =4

But while printing the left value of i will be assigned to ++i values.

Have a look here :

int i=2;
printf("%d %d %d %d %d", i++,++i,++i,i++,i++);
output: 6 7 7 3 2

[weaknessforcats]

@raviroshan
But while printing the left value of i will be assigned to ++i values.

This is an assumption on your part.

If the calling sequence is Pascal, arguments are evaluated left to right, but if it's _cdecl arguments evaluated right to left.

Try to not build restrictions into your code like this.

Also, please not that the order of function argument evauation is not the same as changing a variable more than once in the same sequence point.

Plus when you code (i++,++i,++i,i++,i++); the variables will get incremented but the compiler has until the ; to do it. Different compilers will give you different results.

[Banfa]

raviroshan you are trying to apply logic to an undefined construct and that is just never going to work out well.

On my Windows XP box if I compile your code with MinGW32 (Windows port of gcc) then I get the output 6 7 7 3 2 as you suggested.

On the other hand if on the same computer I use the compiler from VC++ 10 then I get the output 4 4 4 2 2.


As I have already stated, ignoring the order of evaluation of parameters to a function which is platform defined, this code breaks the rules on modifying the value of an object (i in this case) more than once between sequence points. The result of breaking that rule is undefined behaviour and once undefined behaviour has been invoked you can say nothing sensible about what the output might be.

Avoid undefined behaviour.

[suesh]

hello,raviroshan sir can you explain me little bit clearer how 67732 was printed?
thank u sir.

[weaknessforcats]

@suesh:

This is undefined behavior. Any time you change the value of a variable in a single statement you have no idea what different compilers will do with the same code.