Re: C++ Grammar

"Aaron Gray" <aarongray@beeb.net> wrote in message
> Dear All,
> does anyone happen to know or have a more up to date C++ grammar than
> the old comp.compilers one :-
>
> ftp://ftp.iecc.com/pub/file/c++grammar
>
> I think it is dated 1991, and has no template support.
> If anyone has a more uptodate grammar, for any parser generator, other
> than yacc, I would be interested in that as well,


The two most up to date that I'm aware of are John Lilley's, for a
modified version of PCCTS (which can be found via
http://www.polhode.com/pccts.html) and Ed Willink's, as part of his
Flexible Object Generator (via
http://www.computing.surrey.ac.uk/research/dsrg/fog/).


John's uses LL(k), with a large amount of backtracking. It's
moderately easy to understand, but I found it was organised quite
confusingly. He hasn't documented his modifications to PCCTS terribly
well; I found the only way to understand it was to write my own...[1]


Willink's method is a grammar superset which means that the AST must
be subsequently checked to reject any erroneously accepted text, and
to modify the generated tree where the structure has been incorrectly
recognised. This was done because it was necessary to read in
segments of code completely separated from appropriate type and
variable declarations. He's using Bison with some very ad-hoc methods
to perform backtracking and process templates.


My personal suggestion would be to follow the example of Semantic
Designs, who use a Tomita parser (which produces all possible parses
up to the point where it becomes unambiguous, and then you pick the
right one in the case of declaration/expression ambiguities). I now
think that using LL(k) is a false lead, because a lot of the
interesting (and disambiguating) stuff happens at the right-hand end
of productions, not at the left. LR(k) looks more promising, but I
think C++ is naturally LR(2) or (3). This probably needs more
investigation!


--
Mike Dimmick


[1] Not totally successful. I had a number of outstanding warnings I
couldn't get rid of. I now understand why you need to backtrack,
though, and why he's made the modifications he has.

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