2

Possible Duplicate:
What is the correct answer for cout << c++ << c;?

I have following code -

int a= 7;
const int &b = a;
int &c = a;

if I use

cout << endl << ++c << '\t' << a << '\t' << b << '\t' <<  c;

it prints

"8 7 7 8"

however if I use

cout << endl << a << '\t' << b << '\t' << ++c << '\t' << a << '\t' << b << '\t' <<  c;

it prints 

"8 8 8 8 8 8"

How exactly this happens ? Is it something related to optimization ?? If yes, how can i switch it off in ideone.com ???

Community
  • 1
  • 1
ajayg
  • 51
  • 4
  • 3
    There's a duplicate somewhere of what happens when you say `cout << ++c << c;`. I'm not sure exactly where, though. – chris Oct 02 '12 at 02:48
  • http://stackoverflow.com/questions/10782863/what-is-the-correct-answer-for-cout-c-c – nneonneo Oct 02 '12 at 02:50
  • @nneonneo, That's the one, thanks. – chris Oct 02 '12 at 02:53
  • @nneonneo thanks ... so does this mean that this will always be undefined and there is no good explanation of such behaviour ??? – ajayg Oct 02 '12 at 03:29
  • Yes. Undefined behaviour means undefined behaviour. Its output could change depending on the compiler brand, version, flags, stack layout, or code in an entirely different function. Of course you can always explain it by looking at the assembly output, but in general you cannot predict what the compiler will do. – nneonneo Oct 02 '12 at 03:31
  • @ajayg Is totally correct - nneonneo please see the output from my compiler – Adrian Cornish Oct 02 '12 at 03:34
  • Hey - vote for close I get - but a basic programmer would not know why – Adrian Cornish Oct 02 '12 at 04:16

2 Answers2

3

Effectively the operator<< is a function call, c++ is allowed to evaluate the arguments passed to a function in any order it likes, hence the ++c inc is done first, quite legally, by your compiler - mine does something different.

Interstingly my compiler prints

8       8       8       7       7

Some compilers provide switches for order of evaluation of function params, but if you really need to use it I would question myself on the reasons for this as there is something much more wrong with the code and instead write it in a portable way.

Adrian Cornish
  • 23,227
  • 13
  • 61
  • 77
2

a, b, and c are all the same object. The order in which the arguments to functions are evaluate is undefined, however. So, you whatever the compiler chooses to evaluate first is OK. It seems, in your second expression it evaluates ++c first. The way to avoid problems is not to fold the modification with the rest of the expression, i.e., to increment c either before or after the output.

Dietmar Kühl
  • 150,225
  • 13
  • 225
  • 380
  • kuhl .... yeah .. I will not be following this in practice .. I was just trying to some random things and faced this issue .... Does it have anything to do with optimization or something ??? – ajayg Oct 02 '12 at 03:25
  • Most of the time where the order of evaluation isn't defined it is to allow optimization opportunities or to deal with different implementation constraints. – Dietmar Kühl Oct 02 '12 at 03:33