Re: C++ parsing : what's new ?

Zack Weinberg <zackw@panix.com> 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.


Comments?


Tom Payne

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