Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Pre And Post Increment Operator Output

Reply
Thread Tools

Pre And Post Increment Operator Output

 
 
nick_keighley_nospam@hotmail.com
Guest
Posts: n/a
 
      06-22-2012
On Friday, June 22, 2012 11:09:28 AM UTC+1, Bart wrote:
> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > "BartC" <(E-Mail Removed)> writes:
> >>> On 6/21/2012 5:08 PM, BartC wrote:
> >>>> "Yogesh Yadav Pacheria" <(E-Mail Removed)> wrote in message



> >>>>> int i = 0;
> >>>>> i = ++i + ++i + ++i;
> >>>>> printf("%d",i);
> >>
> >>>>> Output should be 6
> >>>>>
> >>>>> But In GCC it's 7
> >>
> >>>> I agree it ought to be 6.


no.

> >> And once you know the result, would you gamble on the same compiler
> >> giving the exactly the same answer one more time?


no. Once I realised the program contained unnecessary undefined behaviour, I'd remove it. No guesses necessary.

> > What would be the point? Don't waste time guessing what the code might
> > do for a given implementation. Just fix it.

>
> OK, so we fix it so that the result is ....? Any guesses?


"a suffusion of yellow"

> Changing the erroneous code so that it stays within the rules:
>
> int i = 0;
> int t1,t2,t3;
>
> t1=++i;
> t2=++i;
> t3=++i;
> i=t1+t2+t3;
> printf("%d",i);
>
> Now gives a valid result. Which happens to coincide with the OP's
> expectations, and with what I said it *ought* to be (for which I was called
> a 'nitwit', even though I went on to explain why the OP wasn't getting that
> result),


a bit harsh but you plainly don't understand what "undefined behavior" means.

> and in fact with what most of my compilers were already giving me
> anyway; presumably they were already using code along the same lines!)


a more mysterious one was posted recently. It was only by looking at the assembler was anyone able to explain the result.

> However, the interesting question is, why anyone - outside c.l.c obviously -
> might think the output of the OP's original code might be 6, rather than any
> other number (or any other manifestation, according to previous threads
> along the same lines).


i = (i + 3) + (i + 3) + (i + 3)
i = i + 3

> Or, are we not allowed to think or guess anything at all, simply because the
> C standard says the original expression has undefined behaviour?


no. If the implementor decides to tell you what the behaviour is- and guarantees the behaviour then you might trust that. Some UB is commonly
used,
unsigned *reg = (unsigned*)0x8010;
*reg = 0x01; // fire lasers

but I can see no point in silly code like this threads
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      06-22-2012
On 6/22/2012 7:30 AM, Noob wrote:
> Eric Sosman wrote:
>
>> Nitwit.

>
> Intentionally or not, a large number of BartC's posts are troll-ish.
> For this reason, I send his messages to the bit bucket.


For someone whose understanding of C is shaky at best (see recent
threads concerning unsigned arithmetic), BartC spouts off an awful lot
of rash opinions. I read his drivel mostly because some of it needs
contradicting lest it mislead readers: "All that is necessary for the
triumph of evil is that good men do nothing." I don't know whether
BartC is actually evil or just a blunderer, but "nitwit" seems fitting
either way.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d


 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      06-22-2012
"BartC" <(E-Mail Removed)> writes:

> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> "BartC" <(E-Mail Removed)> writes:
>>>> On 6/21/2012 5:08 PM, BartC wrote:
>>>
>>>>> "Yogesh Yadav Pacheria" <(E-Mail Removed)> wrote in message

>
>>>>>> int i = 0;
>>>>>> i = ++i + ++i + ++i;
>>>>>> printf("%d",i);
>>>
>>>>>> Output should be 6
>>>>>>
>>>>>> But In GCC it's 7
>>>
>>>>> I agree it ought to be 6.

>
>>> And once you know the result, would you gamble on the same compiler
>>> giving
>>> the exactly the same answer one more time?

>>
>> What would be the point? Don't waste time guessing what the code might
>> do for a given implementation. Just fix it.

>
> OK, so we fix it so that the result is ....? Any guesses?


Argh! Another chasm opens up! There can be no guess. You fix it by
choosing what you want it to mean. You choose it to mean 6, so you "fix
it" (in all senses of the word) by re-writing it as:

> Changing the erroneous code so that it stays within the rules:
>
> int i = 0;
> int t1,t2,t3;
>
> t1=++i;
> t2=++i;
> t3=++i;
> i=t1+t2+t3;
> printf("%d",i);
>
> Now gives a valid result. Which happens to coincide with the OP's
> expectations,


It doesn't just "happen" to coincide -- you forced it to. You have a
view of what the code "really" means, but that's just one rather
arbitrary point of view. To take another, ++i, when i is zero, sets i
to 1 and has the value one. The statement

i = ++i + ++i + ++i;

could, in this context, be taken to mean

i = (i = 1) + (i = 1) + (i = 1);

which is still undefined of course but it looks quite different and your
expectation would probably be different.

The purpose of the sequence point rule (now gone) was to allow the
compiler to say "I know what value ++i has here, and I don't need to
change my mind about that until the next sequence point".

I've never liked the view that anything can happen with undefined code;
it sounds too much like a cheap pedagogical trick to say that the above
could format your drive. But the other extreme -- we all know what
*should* happen, don't we? -- is equally unconvincing. When the C
language does not define the meaning of a bit of code, something else
does, and that's enough for me. I don't want to write code whose
meaning is in the hands of unknown entities. This point of view covers
the much more significant case where I *know* what entity will define
the meaning of otherwise undefined code -- POSIX, for example.

> and with what I said it *ought* to be (for which I was
> called a 'nitwit', even though I went on to explain why the OP wasn't
> getting that result), and in fact with what most of my compilers were
> already giving me anyway; presumably they were already using code
> along the same lines!)
>
> However, the interesting question is, why anyone - outside c.l.c
> obviously -
> might think the output of the OP's original code might be 6, rather
> than any other number (or any other manifestation, according to
> previous threads along the same lines).
>
> Or, are we not allowed to think or guess anything at all, simply
> because the C standard says the original expression has undefined
> behaviour?


Think and guess all you like, but it's disingenuous to suggest that's
all you were doing. You said the value *ought* to be 6 and that's got
to be designed to get a more robust response, no?

--
Ben.
 
Reply With Quote
 
John Bode
Guest
Posts: n/a
 
      06-22-2012
On Thursday, June 21, 2012 11:03:42 PM UTC-5, Yogesh Yadav Pacheria wrote:
> I am new to see and wanna learn it deeply
>
> Could u guyz tell me some good books or web links


For *learning* C:

- "The C Programming Language", Kernighan & Ritchie, 2nd ed.
While a bit out of date (doesn't cover anything after the
C89 standard), it's still one of the best general introductions
to the language.

- "C Programming: A Modern Approach", K.N. King, 2nd ed. While
I don't have any direct experience with this book, people I
trust recommend it highly.

For *working* in C:

- "C: A Reference Manual", Harbison & Steele, 5th ed. My go-to
reference starting with the 2nd edition in the 1980s. Not the
greatest *learning* resource, but invaluable to have at your
side when you're trying to remember how something works.

The Language Standard:

- A publicly available draft of the 2011 standard is available
at the link below:

http://www.open-std.org/jtc1/sc22/wg...docs/n1539.pdf

This isn't the final, official version, but it's close enough
most practical purposes. Again, not a great *learning* resource,
but invaluable to have handy.
 
Reply With Quote
 
Les Cargill
Guest
Posts: n/a
 
      06-22-2012
Ben Bacarisse wrote:
<snip>
>
> Think and guess all you like, but it's disingenuous to suggest that's
> all you were doing. You said the value *ought* to be 6 and that's got
> to be designed to get a more robust response, no?
>


Oy, "is-ought distinction" in c.l.c! To the tune of "anarchy in the UK"...

--
Les Cargill


 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      06-22-2012
John Bode <(E-Mail Removed)> wrote:
>
> - A publicly available draft of the 2011 standard is available
> at the link below:
>
> http://www.open-std.org/jtc1/sc22/wg...docs/n1539.pdf
>
> This isn't the final, official version, but it's close enough
> most practical purposes. Again, not a great *learning* resource,
> but invaluable to have handy.


Even closer is N1570, which is identical to the official version except
for the headers/footers and the addition of diff marks indicating
changes from N1539.
--
Larry Jones

I don't see why some people even HAVE cars. -- Calvin
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-22-2012
"BartC" <(E-Mail Removed)> writes:
> "Keith Thompson" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> "BartC" <(E-Mail Removed)> writes:
>>>> On 6/21/2012 5:08 PM, BartC wrote:
>>>>> "Yogesh Yadav Pacheria" <(E-Mail Removed)> wrote in message
>>>>>> int i = 0;
>>>>>> i = ++i + ++i + ++i;
>>>>>> printf("%d",i);
>>>
>>>>>> Output should be 6
>>>>>>
>>>>>> But In GCC it's 7
>>>
>>>>> I agree it ought to be 6.

>
>>> And once you know the result, would you gamble on the same compiler
>>> giving
>>> the exactly the same answer one more time?

>>
>> What would be the point? Don't waste time guessing what the code might
>> do for a given implementation. Just fix it.

>
> OK, so we fix it so that the result is ....? Any guesses?


No, I don't care to guess, any more than I'd care to guess what value:

srand(0);
printf("%d\n", rand());

"should" print (and that's merely an unspecified result, not undefined
behavior). To know what what it's *supposed* to print, I'd have to ask
the author of the code and find out what he had in mind. My knowledge
of the C language provides no guidance.

> Changing the erroneous code so that it stays within the rules:
>
> int i = 0;
> int t1,t2,t3;
>
> t1=++i;
> t2=++i;
> t3=++i;
> i=t1+t2+t3;
> printf("%d",i);
>
> Now gives a valid result. Which happens to coincide with the OP's
> expectations, and with what I said it *ought* to be (for which I was called
> a 'nitwit', even though I went on to explain why the OP wasn't getting that
> result), and in fact with what most of my compilers were already giving me
> anyway; presumably they were already using code along the same lines!)


Yes, that's one of many possible transformations of the original code
that eliminates the undefined behavior. Other such transformations will
produce different results. Here's mine, which produces the same output
as the original code with gcc:

putchar('7');

> However, the interesting question is, why anyone - outside c.l.c obviously -
> might think the output of the OP's original code might be 6, rather than any
> other number (or any other manifestation, according to previous threads
> along the same lines).
>
> Or, are we not allowed to think or guess anything at all, simply because the
> C standard says the original expression has undefined behaviour?


If someone assumed that the output should be 6, it would probably
because he assumed strict left-to-right evaluation. I would see this as
an opportunity to educate the person with this misconception, and teach
him that the C language does not guarantee, or even imply, any such
evaluation order.

In a professional setting, it doesn't matter what result the original
code produces; it will never survive code review.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-22-2012
John Bode <(E-Mail Removed)> writes:
[...]
> The Language Standard:
>
> - A publicly available draft of the 2011 standard is available
> at the link below:
>
> http://www.open-std.org/jtc1/sc22/wg...docs/n1539.pdf
>
> This isn't the final, official version, but it's close enough
> most practical purposes. Again, not a great *learning* resource,
> but invaluable to have handy.


http://www.open-std.org/jtc1/sc22/wg...docs/n1570.pdf is more
current, and the actual 2011 ANSI C standard is available for $30 from
ANSI at:

http://webstore.ansi.org/RecordDetai...fIEC+9899-2012

<OT>The 2011 C++ standard is also available.</OT>

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      06-22-2012
On 6/22/2012 3:31 PM, Keith Thompson wrote:
>[...]
> In a professional setting, it doesn't matter what result the original
> code produces; it will never survive code review.


Once upon a time, a bug drew my attention to code like

output[i] = f(input[i++]); /* Tricksy */

The executable portion is paraphrased, but the comment is seared
into my memory and is given verbatim. Had it not been there I'd
simply have thought "Ah: Poor schnook doesn't know C very well."
But its presence suggested something rather different, and rather
more culpable: The perpetrator *knew* he was in the wrong, yet
chose to go ahead anyhow -- presumably, because on one of our
eight or nine platforms at whatever optimization level he tried,
the generated code happened to do what he wanted. Oh, yummy.

Thoughts of pickaxes came to me, but I suppressed the urge to
give the offender the treatment he richly deserved. Besides, he
outranked me: He was a Fellow of our engineering department, which
may explain why he got kid-glove treatment in code reviews ...

--
Eric Sosman
(E-Mail Removed)d


 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      06-24-2012
Eric Sosman <(E-Mail Removed)> writes:

> On 6/21/2012 5:08 PM, BartC wrote:
>>
>>
>> "Yogesh Yadav Pacheria" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> I tried this Code
>>>
>>> int main()
>>> {
>>> int i = 0;
>>> i = ++i + ++i + ++i;
>>> printf("%d",i);
>>> }
>>>
>>> Output should be 6
>>>
>>> But In GCC it's 7
>>>
>>> How and plz tell the order of evalution of pre and post bot

>>
>> I agree it ought to be 6.

>
> Nitwit.


Did you not read the rest of his comments? He explained further
on that C allows other possibilities, and this comment is only
expressing an opinion.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Post increment ++ has higher precedence than pre increment ++. Why? Alf P. Steinbach /Usenet C++ 0 05-22-2011 12:03 PM
post increment or pre increment? Peng Yu Perl Misc 7 11-23-2008 11:44 PM
post and pre-increment operator overloading not behaving like simudream@gmail.com C++ 8 11-22-2007 10:20 AM
Why is there no post-pre increment operator in python riteshtijoriwala@gmail.com Python 10 01-13-2006 05:36 PM
Can someone tell me why? (Unary pre and post increment operator Andreas Sheriff C++ 10 09-25-2004 02:33 AM



Advertisments