Archived

This topic is now archived and is closed to further replies.

Unspecified behaviour in C++

This topic is 5146 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''m going over a C++ program for a friend (he can''t find the bug), and I came across the following line:
points[i++] = i++;
My head nearly exploded. Isn''t that unspecified behaviour (not my head exploding but the code ) in C++ (i.e. what autoincrement is done first)?
"Yeah, I would''ve killed you, but I''m glad I didn''t - the paperwork is a bitch"

Share this post


Link to post
Share on other sites
what it the behavior will do is to increment i but since the incrementor is to on the right side (rather than ++i) it will increase the value of i but return the value of i prior to the incrementation.

looking at it seems like its incrementing i on the right side returning its previous value and assigning it to the element in points that will also increment i but be the previous value that was what i equaled to after being incremented.

don't know if that would work, but its weird...

[edited by - nervo on November 10, 2003 6:58:40 AM]

Share this post


Link to post
Share on other sites
I remember a topic like this being spawned awhile back. So just for me to get it straight for this undefined behavior:

Any lvalue begin referenced more than once in any expression will be undefined behavior.

Share this post


Link to post
Share on other sites
quote:
Original post by chacha
quote:
Original post by Nervo
Any lvalue begin referenced more than once in any expression will be undefined behavior.

Not true at all.


well, I was stating that more as a question for someone to confirm it...just to be sure though, I meant being referenced more than once from both sides of the expression. Show me an example if you can exhibiting right and wrong then please.

EDIT: What I said before has too many holes in it...what is meant apparently is that an lvalue that is changed and then assigned back to it will be undefined i.e. the behavior will not be uniform across all implementations.

[edited by - nervo on November 10, 2003 8:33:52 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Nervo
well, I was stating that more as a question for someone to confirm it...just to be sure though, I meant being referenced more than once from both sides of the expression. Show me an example if you can exhibiting right and wrong then please.

EDIT: What I said before has too many holes in it...what is meant apparently is that an lvalue that is changed and then assigned back to it will be undefined i.e. the behavior will not be uniform across all implementations.

Oh, I see what you''re saying now.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
For expressions that have subexpressions, the order in which the subexpressions are evaluated is undefined, which means you can not predict what it will do unless you consult your compiler documentation. Hence, you should not create such expressions because they will be portable and it may even be the case that your compiler does not have a defined order that it evaluates subexpressions in. I believe Stroustrup calls them full expressions.

Share this post


Link to post
Share on other sites
To quote Section 5 paragraph 4 of the standard


Except where noted, the order of evaluation of operands of individual operators and subexpressions of indi-vidual
expressions, and the order in which side effects take place, is unspecified.53) Between the previous
and next sequence point a scalar object shall have its stored value modified at most once by the evaluation
of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored.
The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full
expression; otherwise the behavior is undefined. [Example:
i = v[i++]; // the behavior is unspecified
i = 7, i++, i++; // i becomes 9
i = ++i + 1; // the behavior is unspecified
i = i + 1; // the value of i is incremented
—end example]


Hope that clears it up

Share this post


Link to post
Share on other sites
Thanks guys. It seems it''s not only ''unspecified'' but ''undefined'', as the quote from the standard says!
I need to get a hold of the dude and ask him what he intended and then do a rewrite.



"Yeah, I would''ve killed you, but I''m glad I didn''t - the paperwork is a bitch"

Share this post


Link to post
Share on other sites