tags:

views:

148

answers:

4

i recently came across a question about sequence points in c++ at this site what the code will output:

int c=0;
cout<<c++<<c;

it was answered that the output is undefined and << is not a sequence point but still i want to know why does it that even if i compile it 25 times it still prints 01

+4  A: 

Because always printing 01 is one of the behaviors your program is allowed to have.

avakar
+7  A: 

"Undefined" means that the standard doesn't specify what has to happen in that situation, so anything your compiler does is, by definition, right. If it always prints 01, that's fine. If it prints a different number every time you run, that would be fine too. If it causes monkeys to fly out of your nose (as illustrated here), that would be fine as well.

You might not think so, but the compiler writers are off the hook if it happens.

[Edit: It has been pointed out in the comments that the cannonical reference is "nasal demons", not "nasal monkeys". My apologies for any unintended confusion. Any intended confusion I'm proud of and do not apologize for. :-) ]

T.E.D.
http://blackninjagames.com/images/monkeyundefined.png
GMan
That made me laugh. +1 to the answer and to the comment. :D
Matteo Italia
@Gman: lol. Comment was *soo* appropriate, I had to add it to the answer.
T.E.D.
@GMan: I am so happy that T.E.D. used "nose" instead of some other body part.
James McNellis
Lol. Nobody ever believes me that "nasal monkeys" it the actual technical term for this. I believe Stroustrup even talked about it at one point, but I can't find anything on a search anymore.
T.E.D.
The original term is "nasal demons", I believe. http://catb.org/jargon/html/N/nasal-demons.html
jalf
@jalf: Thank you. I know I've seen it as "Nasal monkeys" (I did find an old Unsenet reference to that from 1997), but I guess that person was probably misremembering "nasal demons".
T.E.D.
+5  A: 

You ask:

why does it that even if i compile it 25 times it still prints 01

and the answer is because compilers are basically (but not totally) deterministic - given the same input, they will produce the same output. in terms of machine code. and that machine code is also deterministic, and so always outputs "01". Another C++ compiler though might, in a similarly deterministic fashion, produce machine code that produces "10" every time.

anon
Also, a future release of your C++ compiler might change it. I have in the past seen (DEC) compilers that will produce better optimized output if they happen to have more free RAM available when the compiler is run, but that is very rare (and tends to appal exeperienced developers when they hear about it).
T.E.D.
@T.E.D. Indeed - the RAM thing is precisely the scenario I had in mind when I said "but not totally".
anon
@T.E.D.: You've got me. I'm indeed appalled.
Donal Fellows
Some compilers will create binaries with different behavior in regards to UB if you specify different options (such as optimization level). But for a given set of options, I agree that compilers are pretty deterministic.
R Samuel Klatchko
+1  A: 
cout<<c++<<c; 

Let us break this down into its parts:

int c1 = c;        // A
c = c + 1;         // B
int c2 = c;        // C
cout << c1 << c2;  // D

Now, what do we know about the order of these operations? A must be before B, and A & C must be before D. Within those limits, they can be in any order. You may expect them to be executed as A-B-C-D, but they could just as validly be executed as A-C-D-B. Or even C-A-D-B. In fact, it would be legal to execute them as A-(B&C)-D, with B & C executed simulataniously on separate CPUs (which would cause a memory access error, which is why this is undefined and not merely implemention-defined behavior)

James Curran