From: Gabriel Dos Reis (Gabriel.Dos-Reis_at_[hidden])
Date: 2002-03-03 12:01:29
Douglas Gregor <gregod_at_[hidden]> writes:
| On Tuesday 26 February 2002 12:28 pm, you wrote:
| > Doees anyone know of a C++-friendly version of yacc, or, better yet, a
| > version of yacc that produces a generic algorithm (e.g., take as input a
| > pair of InputIterators)? Yacc / bison as it stands is quite unfriendly to
| > C++, as you cannot put C++ objects on the evaluation stack, which means
| > that you can't always get objects properly destroyed. You can
| > partially get around this by putting only pointers on the evaluation
| > stack, and having the code that accompanies a production rule be
| > responsible for managing the objects on which it operates, but this scheme
| > breaks down when it comes to error processing -- values get popped off of
| > the evaluation stack without giving you any opportunity to process them.
| I looked around somewhat recently for the same thing, and was unfortunately
| unable to find any generic parser other than Spirit (which I couldn't use
| only because of the fear of adding yet another library). I ended up using
| Bison with lots of pointers, grumbling all the way...
| > The Spirit parser is not what I am looking for, as it is limited to
| > recursive-descent parsing, and is hence unsuitable for many applications
| > (say, parsing a C++ program).
| As Dave Abrahams already mentioned, several of the better C++ parsers uses
| recursive descent parsing.
| This is generally because recursive descent
| parsers handle context sensitivity and arbitrary lookahead _much_ better than
| any Yacc-based solution. Check out gcc/cp/parse.y in the GCC source code to
| see all of the ugliness a Yacc-based parser adds; especially look at the
| comments. Also note that there is an experimental recursive descent parsing
| for GCC that will replace the Yacc-based parser in the future.
I think two things have been being confused here: (a) A parser
written in C++ and, (b) a parser for parsing a C++ program. I think
the original poster was asking for a Yaccish parser *written in* C++.
If so pointing him to gcc/cp/parse.y won't be any clue for him,
because not just because a given parser for C++ happens to go all
imaginable hackery roads means any parser written in C++ would face
the same ugliness.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk