Re: C++ parsing : what's new ?
28 Jan 2002 01:15:43 -0500

          From comp.compilers

Related articles
[4 earlier articles]
Re: C++ parsing : what's new ? (Peter H. Froehlich) (2001-12-29)
Re: C++ parsing : what's new ? (2002-01-03)
Re: C++ parsing : what's new ? (SLK Parsing) (2002-01-03)
Re: C++ parsing : what's new ? (Zack Weinberg) (2002-01-04)
Re: C++ parsing : what's new ? (2002-01-04)
Re: C++ parsing : what's new ? RLWatkins@CompuServe.Com (R. L. Watkins) (2002-01-05)
Re: C++ parsing : what's new ? (2002-01-28)
| List of all articles for this month |

Newsgroups: comp.compilers
Date: 28 Jan 2002 01:15:43 -0500
Organization: University of California, Riverside
References: 01-12-179 02-01-022
Keywords: C++, parse
Posted-Date: 28 Jan 2002 01:15:43 EST

Zack Weinberg <> wrote:
: The motivations are correctness, performance, and better error
: recovery, in that order.

: The existing gcc grammar for C++ does not interpret all language
: constructs correctly; this has been judged unfixable while continuing
: to use yacc. There are already horrible kludges to get certain
: constructs mostly right (look at cp/spew.c, if you want to know) that
: become unnecessary with a recursive descent parser.

: A hand-rolled recursive descent parser has a lot more information
: accessible to it. This should permit it to make better backtracking
: decisions. Bad backtracking is the major cause of bad performance in
: the existing parser. It will certainly permit better error recovery.

: Note that this approach is known to work - the Edison Design Group
: (EDG)'s C/C++ front end uses a hand-written recursive descent parser,
: and it does all the above things better than g++. As someone who's
: worked on both front ends, I can also say that I found it _easier_ to
: work with the recursive descent parser.

I'm interested in this comparision between yacc-generated and
recursive-descent parsers.

It has been my opinion that one should be able to get the best of both
worlds by simply building a parse tree with the yacc generated
bottom-up parser, and then doing whatever else would be done by the
recursive-descent parser during a subsequent top-down traversal of the
syntax tree.

I realize that this approach is overly simplistic, since some
constructs need help from the symbol table in treating different kinds
of identifiers as distinct tokens (i.e., terminal symbols of the cfg).
It would seem, however, that one could get around this difficulty by
perform1ing the second pass on declaration subtrees as soon as they
get constructed.


Tom Payne

Post a followup to this message

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