Related articles |
---|
Parsing C++ manowar@sauropod.engin.umich.edu (1996-11-15) |
Re: Parsing C++ graham.hughes@resnet.ucsb.edu (Graham Hughes) (1996-11-18) |
Re: Parsing C++ nagle@netcom.com (1996-11-18) |
Re: Parsing C++ jsgray@acm.org (Jan Gray) (1996-11-19) |
Re: Parsing C++ jlilley@empathy.com (1996-12-03) |
Re: Parsing C++ dlmoore@ix.netcom.com (David L Moore) (1996-12-07) |
Re: Parsing C++ jlilley@empathy.com (1996-12-09) |
Re: Parsing C++ jlilley@empathy.com (1996-12-09) |
Re: Parsing C++ fjh@mundook.cs.mu.OZ.AU (1996-12-10) |
Re: Parsing C++ davidb@datalytics.com (1996-12-18) |
From: | jlilley@empathy.com (John Lilley) |
Newsgroups: | comp.lang.c++.moderated,comp.compilers |
Date: | 3 Dec 1996 20:44:36 -0500 |
Organization: | Empathy Software |
References: | 96-11-102 |
Keywords: | C++, parse |
manowar@sauropod.engin.umich.edu says...
>I have been reading "The Design and Evolution of C++" book, in which
>Stroustrup mentions that there is considerable difficulty parsing
>C++ with a LALR(1) grammar.
>
>Could someone give me some examples of language features that cause
>problems ? Has anyone made an analysis of what kind of grammar could
>be used to parse C++ without problems ?
Jim Roskind presents an excellent, although not complete analysis of
the difficult ambiguities that C++ poses for LALR(1). It is required
reading, IMHO, for anyone considering the problem.
The "identifier vs. type" problem is not an LALR(1) problem per se.
It has nothing to do with the parser approach -- a parser with
infinite lookahead and backtracking would do no better. The solution
lies in connecting the symbol table to the lexer (or using predicates
ala PCCTS), not in the parser class.
The real LALR(1) ambiguities revolve around issues like declarations vs.
expressions.
You can find Mr. Roskind's analysis at: ftp://ftp.iecc.com/pub/files
john
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.