What should be the output of the following code and why? I am little bit confused.
int a =10;
printf("%d %d %d",a,a=a+10,a);
+19
A:
The output is indeterminate, because a=a+10 is a side-effect, and the compiler is free to evaluate it before or after any of the other parameters.
EDIT: As David points out, the behaviour is actually undefined, which means all bets are off and you should never write such code. In practice, the compiler will almost always do something plausible and unpredictable, maybe even differing between debug and optimised builds. I don't think a sperm whale is a likely outcome. Petunias? Perhaps.
Marcelo Cantos
2010-04-29 09:29:30
Actually, the behavior is undefined, which means that anything the system does (including turning into a sperm whale and a bowl of petunias) is completely in accordance with the Standard.
David Thornley
2010-04-29 14:23:28
Actually Marcelo, We found a bug in our system which was exactly like that. A side effect in an argument. When in debug everything was fine, but when we started to release, demons started flying out of everyones noses. Bloody UB.
daramarak
2010-04-29 23:04:16
+4
A:
Not defined.
The evaluation order of a function parameters is not defined by the standard.
So the output of this could be anything.
shoosh
2010-04-29 09:30:21
+1
A:
It is highly compiler dependent.
Because evaluation order of arguments is not specified by standard.
TheMachineCharmer
2010-04-29 09:30:34
+11
A:
The order of evaluation for a, b, and c in a function call
f(a,b,c)is unspecified.
Read about sequence points to get a better idea: (The undefined behavior in this particular case is not due to sequence points. Thanks to @stusmith for pointing that out)
A sequence point in imperative programming defines any point in a computer program's execution at which it is guaranteed that all side effects of previous evaluations will have been performed, and no side effects from subsequent evaluations have yet been performed. They are often mentioned in reference to C and C++, because the result of some expressions can depend on the order of evaluation of their subexpressions. Adding one or more sequence points is one method of ensuring a consistent result, because this restricts the possible orders of evaluation.
Sequence points also come into play when the same variable is modified more than once. An often-cited example is the expression
i=i++, which both assignsito itself and incrementsi; what is the final value ofi? Language definitions might specify one of the possible behaviors or simply say the behavior is undefined. In C and C++, evaluating such an expression yields undefined behavior.
Amarghosh
2010-04-29 09:36:16
And specifically for this example, the comma does not define a sequence point. This is so that compilers are free to execute function arguments in whatever order they choose, in order to produce the most effecient code.
stusmith
2010-04-29 13:24:48
+2
A:
Not to amend previous correct answers, but a little additional information: according to the Standard, even this would be undefined:
int a =10;
printf("%d %d %d", a = 20, a = 20, a = 20);
Gorpik
2010-04-29 09:42:10
+9
A:
Thanks for the answers.... :) The behavior is really undefined and compiler dependent. Here are some outputs
Compiled with Turbo c : 20 20 10
Compiled with Visual Studio c++: 20 20 20
Compiled with CC: 20 20 20
Compiled with gcc: 20 20 20
Compiled with dev c++: 20 20 10
Just wondering: who really cares about the results ? It is **undefined** behavior anyway !
ereOn
2010-04-29 12:08:56
@ereOn its not about the result: its for verifying that different compilers indeed behave differently instead of blindly believing the answers.
Amarghosh
2010-04-29 12:34:25
@Amarghosh: Even if all tested compilers produced the same results, it would *not* mean that the answers are wrong: it is just one of the infinite possibilities induced by an **undefined** behavior ;)
ereOn
2010-04-29 12:44:09
@ereOn I wasn't suggesting anything towards that. I was just encouraging his attitude: he could have very well thought "oh, it's UB" and stopped there - which is perfectly fine too; but he cared enough to explore it further. I consider that to be a good attitude for a programmer.
Amarghosh
2010-04-29 13:00:43
@ereOn: However, since there were different results, that's at least a strong suggestion that the behavior is implementation-defined, unspecified, or undefined.
David Thornley
2010-04-29 14:24:51
@Amarghosh: However, experimentation on compilers in order to deduce the Standard, and what can be relied on, is not a good thing to do. Experiment if you like, but pay attention to the language definition.
David Thornley
2010-04-29 14:25:55
@David I agree that "experimentation on compilers in order to deduce the Standard" is indeed not a good thing to do; I was just complementing the curiosity.
Amarghosh
2010-04-29 14:56:55
@Amarghosh: My comment was directed to the answer, not your comment. The sentence "The behavior is **really** undefined" can be misleading for some people, because it suggests what David Thornley warned you about.I however agree that testing things is a good attitude for a programmer.
ereOn
2010-04-29 15:32:32