Re: Parsing C++

jlilley@empathy.com (John Lilley)
3 Dec 1996 20:44:36 -0500

          From comp.compilers

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)
| List of all articles for this month |

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
--


Post a followup to this message

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