RAD Studio difference between i++ and ++i

[Sikkirigi]

Hi, I am using RAD Studio XE8 and there's something troubling me.

int q = 1;
q=++q + ++q + ++q;
cout<<q;

Output is: 12

int x = 1;
x=++x + ++x + ++x;
cout<<x;

Output is: 10

int y = 1;
y=++y + ++y + ++y;
cout<<y;

Output is: 8

int z = 1;
z=++z + ++z + ++z;
cout<<z;

Output is: 4

int w = 1;
w=++w + ++w + ++w;
cout<<w;

Output is: 0


How is this all possible? I found this very complicated. What is the logic behind these operations?

[VictorN]

Could you post the complete code reproducing this behavior?

[Arjay]

Where do you use i++ (or y++, x++, etc.)?

[laserlight]

The behaviour is undefined in all the cases that you posted, whether or not you use prefix or postfix operator++. Refer to this FAQ on expressions in C that is applicable to C++. Consequently, there is no "logic behind these operations", at least not any that is well defined.

[2kaud]

As posted, the examples in post #1 are all the same code with different variable names - so the output using the same compiler should be the same!

These examples contain multiple side effects (eg multiple pre/post increment operators using the same variable). The behaviour of code which contain side effects is undefined as the standard does not specify the ordering of these side effects. The result is likely to be different between different compilers and indeed different between different versions from the same vendor!

The bottom line on this is don't write code like this.

[Arjay]

As posted, the examples in post #1 are all the same code with different variable names - so the output using the same compiler should be the same!

It doesn't have to be if the behavior is undefined.

[tiliavirga]

Hi, I am using RAD Studio XE8 and there's something troubling me.

int q = 1;
q=++q + ++q + ++q;
cout<<q;

I've always found the notion of "undefined" strange. Even if something is undefined it could be part of the C++ language specification that a compiler must issue a warning in such cases. Since a compiler must recognize an "undefined" situation anyway such a requirement wouldn't be that much of an extra burden and it would be a great help for the programmer to know.

Anyway, undefined aside, I'd say the most natural equivalent of your one-liner would be,

int q = 1;
++q;
++q;
++q;
q = q + q + q;

Now if that's what you intended then why not do that instead of fooling around with one-liners you (and everybody else) don't understand?

[PredicateNormative]

I've always found the notion of "undefined" strange. Even if something is undefined it could be part of the C++ language specification that a compiler must issue a warning in such cases. Since a compiler must recognize an "undefined" situation anyway such a requirement wouldn't be that much of an extra burden and it would be a great help for the programmer to know.

That would be nice, but I think the intention is, that compiler vendors only need to deal with defined cases and do not have to consider or even identify when an undefined case occurs (although in many cases it wouldn't take much for them to figure that out and provide a warning for the obvious ones - even that would be a help).

Anyway, undefined aside, I'd say the most natural equivalent of your one-liner would be,

int q = 1;
++q;
++q;
++q;
q = q + q + q;

Now if that's what you intended then why not do that instead of fooling around with one-liners you (and everybody else) don't understand?

Unless the OP expected a pre-increment plus then next pre-increment plus the next pre-increment, which effectively resolves to n(q += q+1). e.g.

int q = 1;
q += q+1;
q += q+1;
q += q+1;

Either way, your point still stands, the OP should clearly write what they intend.

[superbonzo]

Even if something is undefined it could be part of the C++ language specification that a compiler must issue a warning in such cases.

this is impossible, generally speaking. Trivial cases aside ( that are already signaled by compilers like clang ), the compiler cannot statically check all such cases due to aliasing issues.

>>Since a compiler must recognize an "undefined" situation anyway

it must not, you don't need to prove that some code is UB-free in order to produce machine code from it.

[tiliavirga]

That would be nice, but I think the intention is, that compiler vendors only need to deal with defined cases and do not have to consider or even identify when an undefined case occurs (although in many cases it wouldn't take much for them to figure that out and provide a warning for the obvious ones - even that would be a help).

Well, undefined behavior is a nasty bug and it beats me why it's allowed to pass in silence. To be warned would mean a lot for programmers and cost very little for compiler writers to implement since all undefined state is detected and known already, you just aren't told.

It must be some kind of oversight.

[laserlight]

Well, undefined behavior is a nasty bug and it beats me why it's allowed to pass in silence. To be warned would mean a lot for programmers and cost very little for compiler writers to implement since all undefined state is detected and known already, you just aren't told.

Have you tried increasing the warning level when compiling? Sikkirigi's examples definitely fall under the "trivial cases" mentioned by superbonzo in post #9, so while there might be debate over whether "all undefined state is detected and known already" via static analysis, there's no contention that the static analysis typically performed by compilers can feasibly detect those cases mentioned, except that they might only warn at higher warning levels.

It must be some kind of oversight.

I think it is a deliberate historical decision not to require compilers to report undefined behaviour. On hindsight we might see it as a bad idea now, but that does not stop compiler authors from implementing such warnings.

[tiliavirga]

I think it is a deliberate historical decision not to require compilers to report undefined behaviour. On hindsight we might see it as a bad idea now, but that does not stop compiler authors from implementing such warnings.

(I always compile cleanly at the the highest warning level.)

I think a language change is motivated considering the severity of the class of bugs we are talking about. We shouldn't be at the mercy of compiler vendors. And in just a few years that will become a historical decision too. A good one.

[tiliavirga]

this is impossible

Certainly, until someone does the impossible and it suddenly becomes possible.

Some languages such as Java are fully defined (including what the OP asked about). That's not the road ahead for C++ but as you say there are a number of "trivial" undefined situations which can easily be detected. It's not far fetched to assume that there are also quite a number of slightly less trivial cases that can be detected with just a little more effort. This in my view is enough to motivate a language change simply because regardless of how trivially detectable an undefined situation is, the bug it causes may be far from trivial.

[superbonzo]

Certainly, until someone does the impossible and it suddenly becomes possible.

this doesn't make much sense to me; if your proposed language change aims at forcing the compiler to detect ALL such cases, then this is and always will be impossible in c++ ( consider an expression a = ++*b + ++*c; called across module boundaries, for example ).

>>there are a number of "trivial" undefined situations which can easily be detected. It's not far fetched to assume that there are also quite a number of slightly less trivial cases that can be detected with just a little more effort. This in my view is enough to motivate a language change simply because regardless of how trivially detectable an undefined situation is, the bug it causes may be far from trivial.

so, you're proposing to detect an arbitrary subset of undefined cases, based off some arbitrary rules buried in the standard that nobody will read and understand ( especially those people these rules are supposed to help ) ??

of course, changing the language in such a way that ALL such cases become defined is possible, but that's not what we're talking about. Just treat built in operators as function calls, and specify a function argument evaluation ordering; this is possible and, with modern inlining compilers, probably it would not have the performance impact historically people feared about ...

[superbonzo]

indeed, according to this ( as of now, accepted ) standard proposal due for c++17, order of evaluation will be fixed for postfix and assignment expressions ( but note that this won't affect the OP use cases anyway ) ...