By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,655 Members | 1,005 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,655 IT Pros & Developers. It's quick & easy.

undefined behaviour

P: n/a
Someone posted earlier an example that looked like taken from the
standard. It was: i = 7, i++, i++; and the result should be 9 (i = 9
in the end)
I thought that the compiler isn't required to do the assignement until
the right hand side expression is fully evaluated. Apparently, the
above expression is handled as:
i = 7;
i++;
i++;
which I don't think is right. Could someone explain, please?

/dan
Jul 19 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
On Tue, 11 Nov 2003 08:24:28 -0800, Dan Cernat wrote:
Someone posted earlier an example that looked like taken from the
standard. It was: i = 7, i++, i++; and the result should be 9 (i = 9
in the end)
I thought that the compiler isn't required to do the assignement until
the right hand side expression is fully evaluated. Apparently, the
above expression is handled as:
i = 7;
i++;
i++;
which I don't think is right. Could someone explain, please?


Yes, it's handled like that. You're almost right about assignment:
operator= has higher precedence than operator, so it's the same as if you
wrote

(i=7),i++,i++

The assignment happens first, followed by a post-increment, followed by a
post-increment. The comma operator inserts a sequence point, so the
behavior isn't undefined.

Josh
Jul 19 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.