1

Possible Duplicate:
Undefined Behavior and Sequence Points

Pleae explain the behaviour of following statements

int b=3;
cout<<b++*++b<<endl;

How will it be calculated?

Community
  • 1
  • 1
Kumar Alok
  • 2,512
  • 8
  • 26
  • 36
  • I checked it in gcc, it gives 16. but I cant understand it. anyways Greg has given a pretty helpful explanation. Thanks – Kumar Alok Aug 02 '11 at 17:53
  • If the result is 16, one possible sequence of actions that would make sense would be: 1. evaluate ++b, returning 4 and storing 4. 2. evaluate b++, returning 4 and storing 5. 3. Multiply the return arguments (4 and 4). Take this with a grain of salt, as mentioned below, this is really undefined. – Greg Howell Aug 02 '11 at 17:58

5 Answers5

4

The behavior here is undefined. See this question

Relevant standard quote:

§5/4.1 Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression.

The most common sequence point is the end of a statement.

Also worth noting from the standard:

§5.2.2/8 The order of evaluation of arguments is unspecified.

Community
  • 1
  • 1
Greg Howell
  • 1,885
  • 1
  • 12
  • 13
  • The second half of your answer is wrong. The order of calls is unspecified, but one call sees all side effects of the other and the other sees no side effects. There are exactly two possible valid results a compiler could produce, which is a lot different from UB. – R.. GitHub STOP HELPING ICE Aug 02 '11 at 17:50
  • @R.. You're right, I'll rephrase. – Greg Howell Aug 02 '11 at 17:51
  • Still not quite right. *Implementation-defined* means the implementation has to define (document) which way it happens. *Unspecified* means it could happen either way (or even different ways different times) and there's no requirement to document it. It's hard to write a correct description of the behavior more specific than "the two calls will take place as if sequentially, but in an unspecified order". – R.. GitHub STOP HELPING ICE Aug 02 '11 at 17:57
  • @R.. I appreciate your returning and correcting this. – Greg Howell Aug 02 '11 at 18:01
1

The standard says this is undefined. The compiler is free to evaluate the statements in any order is sees fit as long as it follows the operator precedence rules. This results in UB:

b++ * ++b; // b is modified more than once
1

The behavior will be undefined as told by others. The output depends upon the implementation of compiler.

But as per the standard it should be undefined.

user872895
  • 21
  • 4
0

AS this is undefined behaviour, one can't tell the end result. The result depends on the implementation.

Rudy Velthuis
  • 28,387
  • 5
  • 46
  • 94
-1

Undefined behavior, Compiler is free to evaluate this expression in any order because of the same precedence of the operators. Consider using

(b++)*(++b)

instead

Vijay Sharma
  • 373
  • 1
  • 10
  • 3
    This is still undefined, as [for primitive types] there are no sequence points anywhere in that expression. This isn't about operator precedence; the compiler has no choice about *when* to perform the various increments, the issue is when the results of those increments become visible. – Dennis Zickefoose Aug 02 '11 at 17:53