Thread: increment and decrement operators in c

> Another interesting example i think is this :
You achieve consistency by introducing a whole load of sequence points ( all those ; )
Since you are only modifying each variable only ONCE between sequence points, your example is well-defined.

The OP's code on the other hand is a pile of crap.
Check out my experiment on UB code compiled with many different compilers (and compiler flags) and marvel in the range of different answers obtained.

> x++ ---> set y equal to x and then increase x by one (so y is now 8 and x 9)
> - --x ---> now first decrease value of x by one and then deduct from y( so y is set to zero and x to 8)
> + ++x ---> now first increase value of x by one and then add it to y(so y is set to 9 and x to 9)
> - x-- ---> now first deduct x from y and then decrease value of x by one(so y is set to 0 and x to
Now study my results carefully, and note that L->R evaluation is not guaranteed, specified or assumed at any point.

Originally Posted by std10093

The behavior is not undefined.If you calculate the result 1000 times,the result is going to be the same every time!

Sorry, but you are the one in error, not Jim.

The code might happen to work consistently for you (with your compiler). It is not guaranteed to work the same way (or even at all) with other compilers, or even with a different version or configuration of your compiler.

The definition of undefined behaviour in the standard is (informally) that anything is allowed to happen. "Anything" can include producing results that you expect, or (in your case) results that lead an uninformed programmer to believe the code has well defined behaviour.

This is undefined behaviour. Consistency for you is not an indication that it is defined behaviour.

This is like saying that on the first run of your program, rand() returns 27. Always. Every time. And therefore it must be the same on every computer in the world. The specification does NOT say that. So anything that calls itself a C compiler could happily do something completely different and still be compliant. And behaviours like that can, as grumpy pointed out, change from compiler to compiler, from version to version (e.g. gcc3 is very different to gcc4 and broke a lot of software that was relying on undefined behaviour), from platform to platform (gcc on 32-bit doesn't work the same as gcc on 64-bit, etc.) and even optimisation level to optimisation level (which is, I think, what will mostly kill this line from working consistently in practice).

If you want to increment or decrement like this, write each step on a separate line (e.g.:

Code:

if(x==8)
{
   y = x++;
   y -= --x;
   y += ++x;
   y -= x--;
}

and the code will DEFINITELY do things in the order you specified. As soon as you put them on one line, the compiler is free to choose whatever the hell it wants to do - note that this is because, as grumpy said, you are modifying the same variables twice - if you weren't, the results would be defined (so long as you didn't do anything else silly). Basically the compiler is able to do whatever ++'s or --'s it wants first when there are multiple things affecting the same variable on the same line. There is no written (or unwritten) rule that says it will evaluate them left-to-right (which would kill performance of something that could otherwise be parallel-executed quite easily) in this particular case even if lots of SIMILAR cases do have such rules in the specification.

It's a bit like the issue with short-circuit evaluation, e.g.:

Code:

if( f() && g() )

will mean that g will NEVER be executed if f() returns FALSE. The difference is that this example is well-defined in the specification, but your multiple-incrementation of the same variable on a single line is NOT (and actually, there are specific warnings against doing that everywhere you read about it).

Don't do it. If this is an exercise question, work it out for yourself as the teacher "wants" you to and point out that it's absolutely, totally, wrong for standardised C.