Post increment operator behavior [duplicate]

Answer 1

Everything I said originally is WRONG! The point in time at which the side-affect is calculated is unspecified. Visual C++ will perform the increment after the call to foo() if test is a local variable, but if test is declared as static or global it will be incremented before the call to foo() and produce different results, although the final value of test will be correct.

The increment should really be done in a separate statement after the call to foo(). Even if the behaviour was specified in the C/C++ standard it would be confusing. You would think that C++ compilers would flag this as a potential error.

Here is a good description of sequence points and unspecified behaviour.

<----START OF WRONG WRONG WRONG---->

The "++" bit of "test++" gets executed after the call to foo. So you pass in (0,0) to foo, not (1,0)

Here is the assembler output from Visual Studio 2002:

mov ecx, DWORD PTR _i$[ebp]
push    ecx
mov edx, DWORD PTR tv66[ebp]
push    edx
call    _foo
add esp, 8
mov eax, DWORD PTR _i$[ebp]
add eax, 1
mov DWORD PTR _i$[ebp], eax

The increment is done AFTER the call to foo(). While this behavior is by design, it is certainly confusing to the casual reader and should probably be avoided. The increment should really be done in a separate statement after the call to foo()

<----END OF WRONG WRONG WRONG ---->

Answer 2

The order of evaluation for arguments to a function is undefined. In this case it appears that it did them right-to-left.

(Modifying variables between sequence points basically allows a compiler to do anything it wants.)

Answer 3

To repeat what others have said, this is not unspecified behavior, but rather undefined. This program can legally output anything or nothing, leave n at any value, or send insulting email to your boss.

As a matter of practice, compiler writers will usually just do what's easiest for them to write, which generally means that the program will fetch n once or twice, call the function, and increment sometime. This, like any other conceivable behavior, is just fine according to the standard. There is no reason to expect the same behavior between compilers, or versions, or with different compiler options. There is no reason why two different but similar-looking examples in the same program have to be compiled consistently, although that's the way I'd bet.

In short, don't do this. Test it under different circumstances if you're curious, but don't pretend that there is a single correct or even predictable result.

Answer 4

This is an example of unspecified behavior. The standard does not say what order arguments should be evaluated in. This is a compiler implementation decision. The compiler is free to evaluate the arguments to the function in any order.

In this case, it looks like actually processes the arguments right to left instead of the expected left to right.

In general, doing side-effects in arguments is bad programming practice.

Instead of foo(test++, test); you should write foo(test, test+1); test++;

It would be semantically equivalent to what you are trying to accomplish.

Edit: As Anthony correctly points out, it is undefined to both read and modify a single variable without an intervening sequence point. So in this case, the behavior is indeed undefined. So the compiler is free to generate whatever code it wants.