Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > About C and order of evaluation

Reply
Thread Tools

About C and order of evaluation

 
 
charpour@yahoo.com
Guest
Posts: n/a
 
      10-08-2007
Hello, in the program below:

#include <stdio.h>

int main(void) {
int x = 1, y = 2, z;

z = x+++y;
return 0;
}

after executing, z has the value of 3, x is 2 and y is 2.

Can someone please explain me in detail why it is treated by the
compiler as (x++)+y and not for example as x+(++y) ?
What steps the compiler does to produce that result ?

Thanks for your time and sorry for my bad english

Charalampos Pournaris

 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      10-08-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) said:

<snip>

> z = x+++y;
> return 0;
> }
>
> after executing, z has the value of 3, x is 2 and y is 2.
>
> Can someone please explain me in detail why it is treated by the
> compiler as (x++)+y and not for example as x+(++y) ?


This is because of what is sometimes known as "maximum munch". The
preprocessor (which is responsible for converting the program into what
are called "preprocessing tokens" - "pp-tokens" for short) grabs the
largest token it can from the code stream. That is, it breaks off the
biggest piece it can chew.

Thus, z = x+++y; is parsed as

[z] [=] [++] [+] [y]

This is why x+++++y is not legal C, even though we can imagine how it might
be. We might think it's the same as x++ + ++y, but the preprocessor sees
it as [x] [++] [++] [+] [y] which is illegal.

Standard ref:

3.1 LEXICAL ELEMENTS

Semantics, para 2:

"If the input stream has been parsed into preprocessing tokens up to a
given character, the next preprocessing token is the longest sequence of
characters that could constitute a preprocessing token."

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
 
 
 
karthikbalaguru
Guest
Posts: n/a
 
      10-08-2007
On Oct 8, 7:39 am, Richard Heathfield <(E-Mail Removed)> wrote:
> (E-Mail Removed) said:
>
> <snip>
>
> > z = x+++y;
> > return 0;
> > }

>
> > after executing, z has the value of 3, x is 2 and y is 2.

>
> > Can someone please explain me in detail why it is treated by the
> > compiler as (x++)+y and not for example as x+(++y) ?

>
> This is because of what is sometimes known as "maximum munch". The
> preprocessor (which is responsible for converting the program into what
> are called "preprocessing tokens" - "pp-tokens" for short) grabs the
> largest token it can from the code stream. That is, it breaks off the
> biggest piece it can chew.
>
> Thus, z = x+++y; is parsed as
>
> [z] [=] [++] [+] [y]
>
> This is why x+++++y is not legal C, even though we can imagine how it might
> be. We might think it's the same as x++ + ++y, but the preprocessor sees
> it as [x] [++] [++] [+] [y] which is illegal.
>
> Standard ref:
>
> 3.1 LEXICAL ELEMENTS
>
> Semantics, para 2:
>
> "If the input stream has been parsed into preprocessing tokens up to a
> given character, the next preprocessing token is the longest sequence of
> characters that could constitute a preprocessing token."
>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
> "Usenet is a strange place" - dmr 29 July 1999


Interesting

Karthik Balaguru

 
Reply With Quote
 
charpour@yahoo.com
Guest
Posts: n/a
 
      10-08-2007
On Oct 8, 5:39 am, Richard Heathfield <(E-Mail Removed)> wrote:
> (E-Mail Removed) said:
>
> <snip>
>
> > z = x+++y;
> > return 0;
> > }

>
> > after executing, z has the value of 3, x is 2 and y is 2.

>
> > Can someone please explain me in detail why it is treated by the
> > compiler as (x++)+y and not for example as x+(++y) ?

>
> This is because of what is sometimes known as "maximum munch". The
> preprocessor (which is responsible for converting the program into what
> are called "preprocessing tokens" - "pp-tokens" for short) grabs the
> largest token it can from the code stream. That is, it breaks off the
> biggest piece it can chew.
>
> Thus, z = x+++y; is parsed as
>
> [z] [=] [++] [+] [y]
>
> This is why x+++++y is not legal C, even though we can imagine how it might
> be. We might think it's the same as x++ + ++y, but the preprocessor sees
> it as [x] [++] [++] [+] [y] which is illegal.
>
> Standard ref:
>
> 3.1 LEXICAL ELEMENTS
>
> Semantics, para 2:
>
> "If the input stream has been parsed into preprocessing tokens up to a
> given character, the next preprocessing token is the longest sequence of
> characters that could constitute a preprocessing token."
>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
> "Usenet is a strange place" - dmr 29 July 1999


Very interesting, thank you

 
Reply With Quote
 
charpour@yahoo.com
Guest
Posts: n/a
 
      10-08-2007
One more question,

The "maximum munch" on pp-tokens is always applied from left to right?
(The pp reads the stream in left->right order?)

Thanks

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      10-08-2007
(E-Mail Removed) said:

> One more question,
>
> The "maximum munch" on pp-tokens is always applied from left to right?
> (The pp reads the stream in left->right order?)


Yes.

Incidentally, I hope I didn't confuse you when I wrote:

Thus, z = x+++y; is parsed as

[z] [=] [++] [+] [y]

What I should have written is of course:

Thus, z = x+++y; is parsed as

[z] [=] [x] [++] [+] [y] [;]

Oops!

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
David Mathog
Guest
Posts: n/a
 
      10-09-2007
Richard Heathfield wrote:

> Thus, z = x+++y; is parsed as
>
> [z] [=] [x] [++] [+] [y] [;]


The compiler may be happy with that code but I sure wouldn't be pleased
if it showed up in a program I had to maintain. It _looks_ like a typo,
and without analyzing the surrounding lines there's no way to tell if:

z = (x++)+y;

or

z = x+(++y);

was intended. This is another one of those instances where C
is a little too flexible (for my taste) about the syntax it will accept.
Sometimes it would be better if the compilers warned the
programmers to put in a few more spaces or parentheses so that the
meaning of the code would be unambiguous. That is unambiguous without
having to know arcane details about the how the compiler's parser
functioned.

Here's Hello World with all "extra" spaces and EOL's removed.
It's down to just 3 lines and two spaces: one between "int" and "main"
and one between "Hello" and "world". My news client wrapped this after
the second space but in the original it was only a 3 line program.

#include <stdlib.h>
#include <stdio.h>
int main(void){(void)fprintf(stdout,"Hello
world\n");(void)exit(EXIT_SUCCESS);}

This 3 line form is legal but it's also really hard to read. It would
be nice if gcc (for instance) had at least an optional -Whuman, to issue
warnings for difficult to read but otherwise legal constructs.


Regards,

David Mathog


 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      10-09-2007
David Mathog wrote:

> Richard Heathfield wrote:
>
>> Thus, z = x+++y; is parsed as
>>
>> [z] [=] [x] [++] [+] [y] [;]

>
> The compiler may be happy with that code but I sure wouldn't be
> pleased
> if it showed up in a program I had to maintain. It _looks_ like a
> typo, and without analyzing the surrounding lines there's no way to
> tell if:
>
> z = (x++)+y;
>
> or
>
> z = x+(++y);
>
> was intended. This is another one of those instances where C
> is a little too flexible (for my taste) about the syntax it will
> accept.
> Sometimes it would be better if the compilers warned the
> programmers to put in a few more spaces or parentheses so that the
> meaning of the code would be unambiguous. That is unambiguous without
> having to know arcane details about the how the compiler's parser
> functioned.


It's not the compiler's job to teach the programming best coding
practices. No one prevents someone from writing clear, well formatted
source. Unfortunately too many C programmers have IOCCC ambitions.
Witness the recent thread started by Antoninus Twink complaining about
a piece of clear C code.

> Here's Hello World with all "extra" spaces and EOL's removed.
> It's down to just 3 lines and two spaces: one between "int" and "main"
> and one between "Hello" and "world". My news client wrapped this
> after the second space but in the original it was only a 3 line
> program.
>
> #include <stdlib.h>
> #include <stdio.h>
> int main(void){(void)fprintf(stdout,"Hello
> world\n");(void)exit(EXIT_SUCCESS);}
>
> This 3 line form is legal but it's also really hard to read. It would
> be nice if gcc (for instance) had at least an optional -Whuman, to
> issue warnings for difficult to read but otherwise legal constructs.


This is a subjective decision and I think, though I'm not sure, it will
be rather hard to implement. This is something that the programmer must
learn from good books and peers, not a compiler, IMHO.

 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      10-10-2007
David Mathog wrote:

> Richard Heathfield wrote:
>
>> Thus, z = x+++y; is parsed as
>>
>> [z] [=] [x] [++] [+] [y] [;]

>
> The compiler may be happy with that code but I sure wouldn't be pleased
> if it showed up in a program I had to maintain.


"It's specified. But anyone who writes code like that should be
transmogrified into earthworms and fed to ducks."

I can't find the original, only echoes in sign-quotes, alas.

--
Chris "transmogrified ducks dollin" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

 
Reply With Quote
 
David Mathog
Guest
Posts: n/a
 
      10-10-2007
santosh wrote:
> David Mathog wrote:


>> Sometimes it would be better if the compilers warned the
>> programmers to put in a few more spaces or parentheses so that the
>> meaning of the code would be unambiguous. That is unambiguous without
>> having to know arcane details about the how the compiler's parser
>> functioned.

>
> It's not the compiler's job to teach the programming best coding
> practices. No one prevents someone from writing clear, well formatted
> source. Unfortunately too many C programmers have IOCCC ambitions.
> Witness the recent thread started by Antoninus Twink complaining about
> a piece of clear C code.


Teach no, help with, yes. For the sake of argument, imagine that a
compiler had options like:

-Wfor_humans warn on difficult to read code
-Wstyle_fmt1 warn on source code not in specified style

Where the first would catch the "x+++y", and the second would pick up
on deviations from a specified coding style. These would be immensely
helpful, even if they have no effect whatsoever on the code generated.
Here is an example of the type of style variant I would love to be able
to flag.

if(some_condition)
do_something();

The lack of {} around the conditional code very often leads to errors
during code maintenance, and this can happen by accident when a stray
carriage return falls in the wrong place or an automatic line wrap
occurs unnoticed. Also, many projects have coding style standards, but
these are currently impossible to enforce using just the compiler. Some
projects want:


if(some_condition){
if(something_else){
}
}
else{
}

and another may demand:

if(some_condition) {
if(something_else) {
}
}
else {
}

It would be incredibly useful for me in these situations to be able to
throw a compiler switch to check for variation from these styles. The
compiler is clearly a good place to do this since it has to parse the
code thoroughly anyway, and could easily add a few more rules during
that parsing to pick up on things like indent levels, bracket spacing,
and split line if statements.

Regards,

David Mathog
 
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
function argument evaluation order and asserts and macros jacek.dziedzic@gmail.com C++ 4 09-24-2008 02:28 PM
expression and evaluation order and precedence rules silpau@gmail.com C Programming 26 06-15-2007 03:53 PM
[EVALUATION] - E03 - jamLang Evaluation Case Applied to Python Ilias Lazaridis Python 2 04-24-2005 05:29 PM
[EVALUATION] - E04 - jamPersist Evaluation Case Applied to Ruby Ilias Lazaridis Ruby 18 04-09-2005 04:45 PM
[EVALUATION] - E03 - jamLang Evaluation Case Applied to Ruby Ilias Lazaridis Ruby 74 04-04-2005 05:29 PM



Advertisments