Re: C++ intermediate representation. (Greg Comeau)
15 May 2005 15:45:44 -0400

          From comp.compilers

Related articles
[6 earlier articles]
Re: C++ intermediate representation. (Ralph Boland) (2005-05-14)
Re: C++ intermediate representation. (Chris F Clark) (2005-05-14)
Re: C++ intermediate representation. (Sean Case) (2005-05-14)
Re: C++ intermediate representation. (Robert H) (2005-05-15)
Re: C++ intermediate representation. (Gabriel Dos Reis) (2005-05-15)
Re: C++ intermediate representation. (2005-05-15)
Re: C++ intermediate representation. (2005-05-15)
Re: C++ intermediate representation. (2005-05-15)
Re: C++ intermediate representation. (2005-05-15)
Re: C++ intermediate representation. (bjarne) (2005-05-15)
RE: C++ intermediate representation. (Quinn Tyler Jackson) (2005-05-15)
Re: C++ intermediate representation. (Chris F Clark) (2005-05-16)
Languages that are hard to parse (Steve) (2005-05-16)
[17 later articles]
| List of all articles for this month |

From: (Greg Comeau)
Newsgroups: comp.compilers
Date: 15 May 2005 15:45:44 -0400
Organization: Comeau Computing;
References: 05-05-078 05-05-081
Keywords: C++, parse
Posted-Date: 15 May 2005 15:45:44 EDT

Quinn Tyler Jackson <> wrote:
>> Aaron Gray <> wrote:
>> >Parsing C++ properly is no mean feat. C++'s grammar is ambiguous...
>> >The new GCC's 3.4.x and 4.0 both use recursive descent with
>> >backtracking parser technology rather than LALR(1) or Generalized LR.
>To which Henry Spencer replied:
>> In his "The Design and Evolution of C++", Stroustrup says that he let
>> Aho and Johnson talk him out of writing his own recursive-descent
>> parser for C++... and he now thinks that was a big mistake.
>In 2003 (9 years after the D&E statement), I asked if he still believed
>that, and he most certainly stood behind his statement.

I'm certain, since I had those same thoughts re other compilers I've
written, and on earlier versions of Comeau C++ which were based on
cfront at the time, and so I discussed this with him extensively about
a dozen years ago.

>(Stroustrup states recently that "today, most production C++
>compilers have hard-coded recursive descent parsers. Note that part
>of the reason for that is compactness, speed, and quality of error
>messages." [Stroustrup 2003])

>(The formal citation because I include that comment in a paper that
>has a section on C++ parsing.)


>As someone who has attempted to write a complete formal grammar
>specification for C++ without jimmying and ad hockery -- I attest to
>the fact that it's one nasty language to parse -- but a great test of
>a grammar formalism!

If nothing else, a lot of fun :) After all, programming should be
enjoyable, right?

I have to confess that I have not taken a look since about 1999 to see
what the tools available today are, but at least until then, the
(generally available) tools could not hack it. Either they were slow,
hard to work with, had bugs, could not produce code that could be
compiled, couldn't talk with other parts of itself well, etc. So,
while I am not convinved there is a guarantee that hand coded parsers
results in all those things, certainly at the time it was the only
sensible thing to do, and probably still is today.

To the OP: You are up against a pretty hard task, even with the
assumption of valid input. Take any time estimates and multiply it by
Greg Comeau / Comeau for the Mac? Stay tuned.
Comeau C/C++ ONLINE ==>
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.