Velocity Reviews > Funny results with increment decrement operators

# Funny results with increment decrement operators

cpptutor2000@yahoo.com
Guest
Posts: n/a

 02-16-2008

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

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++;

Glenn Hutchings
Guest
Posts: n/a

 02-16-2008
On Feb 16, 12:00 am, "(E-Mail Removed)" <(E-Mail Removed)>
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
This instance of it involves a no-no with sequence points.

Ian Collins
Guest
Posts: n/a

 02-16-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>

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

--
Ian Collins.

CBFalconer
Guest
Posts: n/a

 02-16-2008
"(E-Mail Removed)" wrote:
>
>
> int x = 20, y = 35;
> x = x++ + y++;
> y = ++x + ++y;
> printf("%d %d\n", x, y);
>
> The answers are 57, 94

invokes undefined behaviour.

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

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

Martin Ambuhl
Guest
Posts: n/a

 02-16-2008
(E-Mail Removed) wrote:
>
> int x = 20, y = 35;
> x = x++ + y++;

[etc.]

Before posting to a newsgroup, it is expected that you follow it for a
while first. This can be done with the archives in Google Groups, and
will tell you what sorts of questions are topical. It will also, as in
this case, give you the answer to your question, since every few days
some clueless person posts a variation on it.

Before posting to a newsgroup, it is expected that you will check the
FAQ. In this case, you would have found

<http://c-faq.com/expr/evalorder1.html> "Q: Why doesn't this code: a[i]
= i++; work?"

<http://c-faq.com/expr/evalorder2.html> "Q: Under my compiler, the code
int i = 7; printf("%d\n", i++ * i++); prints 49. Regardless of the order
of evaluation, shouldn't it print 56?"

<http://c-faq.com/expr/ieqiplusplus.html> "Q: I've experimented with the
code int i = 3; i = i++; on several compilers. Some gave i the value 3,
and some gave 4. Which compiler is correct?"

And you want to read this:
<http://c-faq.com/ansi/undef.html> "Q: People seem to make a point of
distinguishing between implementation-defined, unspecified, and
undefined behavior. What do these mean?"

And change your id. You are not ready to be a tutor for either C or (as
it implies) C++.

MisterE
Guest
Posts: n/a

 02-16-2008

> 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++;
>

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
Guest
Posts: n/a

 02-16-2008
In article <47b6377a\$0\$12542\$(E-Mail Removed)> ,
MisterE <(E-Mail Removed)> wrote:

>> 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

Guest
Posts: n/a

 02-16-2008
MisterE wrote:
>> 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++;
>>

>
> 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.

When I am learning a package or tool without adequate documentation I often
perform such boundary tests to further clarify the functionality in my
mind. The results let me use it as a dependable tool rather than a fragile
tool that may or may not do what I expect.

For embedded work, where code space and speed are often important I compile
alternative constructs to see the effects on the code. I learn my
compiler's strengths and weaknesses that way.

When I am testing my own code, I often make strange function requests to
verify that it works as I expect under abnormal, as well as normal conditions.

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.

--

CBFalconer
Guest
Posts: n/a

 02-17-2008
>

.... 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://www.dinkumware.com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>

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

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

Keith Thompson
Guest
Posts: n/a

 02-18-2008
CBFalconer <(E-Mail Removed)> writes:
[...]
> 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://www.dinkumware.com/refxc.html> (C-library}
> <http://gcc.gnu.org/onlinedocs/> (GNU docs)
> <http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>

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_Keith) <(E-Mail Removed)>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"