Re: C++ Grammar - Update

> > The major reported problem with the C++ syntax is that it requires
> > semantic information to parse correctly. This isn't strictly true,
> > one can follow the technique of Ed Willink
> > (http://www.computing.surrey.ac.uk/research/dsrg/fog/FogThesis.html)


> Please note that the goal of that parser is restricted to parsing
> declarations only (see 4.4, Ambiguity resolution).


Or, you can implement any parsing engine that is willing to enumerate
locally ambiguous parses, such as GLR (aka Tomita) parsers. These
allow you to parse the entire language, and build complete syntax
trees. The trick is to realize that you can use semantic information
collected *later* to eliminate the ambiguities you don't want.


Our DMS Reengineering Toolkit uses technology. It parses C++ just
fine (if you leave out dark-corner complications caused by macros and
preprocessor conditionals; if you simply expand those, it parses the
complete language).


> It seems that the parser accepts a *very* large superset of C++,
> e.g. the provided Solaris binary accepts
>
> void foo(){
> +
> }
>
> without complaints. So I still doubt that you can do meaningful C++
> parsing w/o semantic analysis in the lexer.


Most parsing engines accept "syntax" which is not legal for the
language at hand, and simply eliminate the illegal combinations using
information outside the scope of the parser.
[I'll admit this looks worse than normal].


> > One must know whether a construct names a type in order to correctly
> > parse in some circumstances.


No, you just get multiple local parses.


> There are actually ambiguities in this area, consider
>
> class X{
> friend A::B::C();
> };
>
> Is this ::C, returning A::B, or is it ::B::C, returning A? This is
> currently an ambiguity in C++, which is not resolved in the '98
> edition of the standard.


We get both parses, if both are legal. What you do about ambiguities
allowed by the langauge after semantic processing is a matter of
taste. We presently don't do any name/type resolution on C++, but
what we typically do when this happens (it does occur in other legacy
languages that are not so well defined) is to simply discard one of
the parse trees with a warning message.


> > I conclude that C++ requires some very strong parsing methods if one
> > is to be successful.


I'd agree.


--
Ira D. Baxter, Ph.D. CTO Semantic Designs, Inc.
http://www.semdesigns.com

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