Funny results with increment decrement operators

[cpptutor2000@yahoo.com]

Could some C guru please help ? I have:

int x = 20, y = 35;
x = x++ + y++;
y = ++x + ++y;
printf("%d %d\n", x, y);

The answers are 57, 94

I tried reasoning using the standard C semantics that ++x means 'first
increment and then do something else', as copared to x++ which is
'first do something else and then increment'.
So, x = x++ + y++; results in x = (20 + 35) + 1 = 56 and y = 36
and then y = ++x + ++y; results in (56+1) + (36+1) = 57 + 37 = 94
Where is the 57 coming from, for x = x++ + y++;

I am using gcc. Thanks in advance for your helpful hints.

[Glenn Hutchings]

Re: Funny results with increment decrement operators

On Feb 16, 12:00 am, "cpptutor2...@y ahoo.com" <cpptutor2...@y ahoo.com>
wrote:

Where is the 57 coming from, for x = x++ + y++;

Ah, y'see. What you have going on here is "undefined behaviour".
Basically, the compiler can make up any value it likes, and you can't
complain. See
http://en.wikipedia.org/wiki/Undefined_behavior for some more info.
This instance of it involves a no-no with sequence points.

[Ian Collins]

Re: Funny results with increment decrement operators

cpptutor2000@ya hoo.com wrote:

Could some C guru please help ? I have:
>

You could have helped your self by looking back less than a day in this
group.

--
Ian Collins.

[MisterE]

Re: Funny results with increment decrement operators

I tried reasoning using the standard C semantics that ++x means 'first
increment and then do something else', as copared to x++ which is
'first do something else and then increment'.
So, x = x++ + y++; results in x = (20 + 35) + 1 = 56 and y = 36
and then y = ++x + ++y; results in (56+1) + (36+1) = 57 + 37 = 94
Where is the 57 coming from, for x = x++ + y++;
>
I am using gcc. Thanks in advance for your helpful hints.

Off-topic slightly but why do this constantly come up? Do people actually
try coding like this? and get stuck wondering why it doesn't work. Why don't
people just save them and everyone and just put i++; on the next statement.

[Richard Tobin]

Re: Funny results with increment decrement operators

In article <47b6377a$0$125 42$afc38c87@new s.optusnet.com. au>,
MisterE <voids@sometwhe r.worldwrote:

>So, x = x++ + y++; results in x = (20 + 35) + 1 = 56 and y = 36
>and then y = ++x + ++y; results in (56+1) + (36+1) = 57 + 37 = 94

>Off-topic slightly but why do this constantly come up? Do people actually
>try coding like this?

Many of them come from stupid puzzles set by uninspired teachers and
interviewers.

In real life, people rarely write examples as obvious as the ones
above. But more complicated examples where the side effect is buried
in array subscripts and the like are probably more common, and
invisible examples in macros even more so.

-- Richard
--
:wq

[CBFalconer]

Re: Funny results with increment decrement operators

"cpptutor2000@y ahoo.com" wrote:

>
Could some C guru please help ? I have:
>
int x = 20, y = 35;
x = x++ + y++;
y = ++x + ++y;
printf("%d %d\n", x, y);
>
The answers are 57, 94

The answers are correct, as are any other answers. The program
invokes undefined behaviour.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Re: Funny results with increment decrement operators

Thad Smith wrote:

>

.... snip ...

>
In the case mentioned, there is a readily available standard for
C, but many people don't know it exists, don't know how get it,
or don't know how to interpret it. There is the additional
important question of whether the compiler you are using
supports a particular standard feature.

If the compiler doesn't include any standard C features, it is
deficient, and you are fully justified in demanding your money
back. Exception - when it publishes its deficencies, as does gcc.

Some useful references about C (C99 are standards):
<http://www.ungerhu.com/jxh/clc.welcome.txt >
<http://c-faq.com/ (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf(C99)
<http://cbfalconer.home .att.net/download/n869_txt.bz2(C9 9, txt)
<http://www.dinkumware. com/refxc.html (C-library}
<http://gcc.gnu.org/onlinedocs/ (GNU docs)
<http://clc-wiki.net/wiki/C_community:com p.lang.c:Introd uction>

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

Re: Funny results with increment decrement operators

CBFalconer <cbfalconer@yah oo.comwrites:
[...]

Some useful references about C (C99 are standards):
<http://www.ungerhu.com/jxh/clc.welcome.txt >
<http://c-faq.com/ (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf(C99)
<http://cbfalconer.home .att.net/download/n869_txt.bz2(C9 9, txt)
<http://www.dinkumware. com/refxc.html (C-library}
<http://gcc.gnu.org/onlinedocs/ (GNU docs)
<http://clc-wiki.net/wiki/C_community:com p.lang.c:Introd uction>

Let me point out one more time that n869_txt.bz2 is not a standard;
it's a draft of the C99 standard. Its only advantage is that (once
you decompress it with bunzip2) it's plain text; that can also be a
disadvantage, since some important formatting information is lost (for
example, definitions of terms are indicated with italics). Some
changes were made between n869 and the official release of the C99
standard. Still more post-C99 changes were made in three Technical
Corrigenda, which are incorporated into n1256.pdf.

My advice: consider using n869 *only* if the ability to use plain text
rather than PDF is very important to you. If you have a decent PDF
reader and don't mind using it, use n1256.pdf.

Yes, n1256 is also a draft, but it incorporates the official C99
standard and all three official technical corrigenda. If you're even
more of a sticker for accuracy than I am (wow!), then you can pay for
a copy of the actual C99 standard ($18 when I bought it, probably a
little more now) and obtain all three TCs at no charge.

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[John Bode]

Re: Funny results with increment decrement operators

On Feb 15, 7:00 pm, "cpptutor2...@y ahoo.com" <cpptutor2...@y ahoo.com>
wrote:

Could some C guru please help ? I have:
>
int x = 20, y = 35;
x = x++ + y++;
y = ++x + ++y;
printf("%d %d\n", x, y);
>
The answers are 57, 94
>
I tried reasoning using the standard C semantics that ++x means 'first
increment and then do something else', as copared to x++ which is
'first do something else and then increment'.

You have the semantics slightly wrong. The expression "++x" evaluates
to the current value of x + 1, and as a *side effect*, x will be
incremented. Exactly *when* x gets incremented is somewhat variable,
as long as it occurs before the next sequence point. So x may be
incremented immediately after the expression is evaluated, or it may
not be incremented until after all expressions have been evaluated.

For example, given the statement

x = y++ * --z;

the compiler is free to evaluate it as follows:

t1 <- z - 1
t2 <- y
x <- t2 * t1
y <- y + 1
z <- z - 1

Attempting to modify an object more than once between sequence points
invokes undefined behavior; *any* result is correct.

Go to http://www.c-faq.com and read Section 3, and pay particular
attention to question 3.8.

Any expression of the forms

x = x++
x++ + x++
a[i] = i++

will invoke undefined behavior.