-
January 8th, 2016, 04:34 PM
#1
RAD Studio difference between i++ and ++i
Hi, I am using RAD Studio XE8 and there's something troubling me.
Code:
int q = 1;
q=++q + ++q + ++q;
cout<<q;
Output is: 12
Code:
int x = 1;
x=++x + ++x + ++x;
cout<<x;
Output is: 10
Code:
int y = 1;
y=++y + ++y + ++y;
cout<<y;
Output is: 8
Code:
int z = 1;
z=++z + ++z + ++z;
cout<<z;
Output is: 4
Code:
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?
-
January 8th, 2016, 05:30 PM
#2
Re: RAD Studio difference between i++ and ++i
Could you post the complete code reproducing this behavior?
Victor Nijegorodov
-
January 8th, 2016, 05:43 PM
#3
Re: RAD Studio difference between i++ and ++i
Where do you use i++ (or y++, x++, etc.)?
-
January 8th, 2016, 09:46 PM
#4
Re: RAD Studio difference between i++ and ++i
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.
-
January 9th, 2016, 06:08 AM
#5
Re: RAD Studio difference between i++ and ++i
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.
All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!
C++23 Compiler: Microsoft VS2022 (17.6.5)
-
January 9th, 2016, 12:58 PM
#6
Re: RAD Studio difference between i++ and ++i
Originally Posted by 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!
It doesn't have to be if the behavior is undefined.
-
January 11th, 2016, 05:20 AM
#7
Re: RAD Studio difference between i++ and ++i
Originally Posted by Sikkirigi
Hi, I am using RAD Studio XE8 and there's something troubling me.
Code:
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,
Code:
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?
-
January 11th, 2016, 06:05 AM
#8
Re: RAD Studio difference between i++ and ++i
Originally Posted by tiliavirga
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).
Originally Posted by tiliavirga
Anyway, undefined aside, I'd say the most natural equivalent of your one-liner would be,
Code:
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.
Code:
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.
Last edited by PredicateNormative; January 11th, 2016 at 06:10 AM.
-
January 11th, 2016, 09:49 AM
#9
Re: RAD Studio difference between i++ and ++i
Originally Posted by tiliavirga
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.
-
January 11th, 2016, 10:07 AM
#10
Re: RAD Studio difference between i++ and ++i
Originally Posted by PredicateNormative
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.
Last edited by tiliavirga; January 11th, 2016 at 10:22 AM.
-
January 11th, 2016, 10:40 AM
#11
Re: RAD Studio difference between i++ and ++i
Originally Posted by tiliavirga
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.
Originally Posted by tiliavirga
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.
-
January 11th, 2016, 11:40 AM
#12
Re: RAD Studio difference between i++ and ++i
Originally Posted by laserlight
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.
-
January 11th, 2016, 12:22 PM
#13
Re: RAD Studio difference between i++ and ++i
Originally Posted by superbonzo
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.
-
January 12th, 2016, 03:41 AM
#14
Re: RAD Studio difference between i++ and ++i
Originally Posted by tiliavirga
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 ...
-
January 12th, 2016, 04:22 AM
#15
Re: RAD Studio difference between i++ and ++i
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 ) ...
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|