Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!uunet!mcsun!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: gnu.g++.bug
Subject: Re: g++ 1.36.1 bug 900207.03
Summary: Not a bug, a limitation of LR(1) parsing?
Message-ID: <1631@aber-cs.UUCP>
Date: 9 Feb 90 21:35:06 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: gnu
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 32

In article <9002071710.aa07537@ICS.UCI.EDU> rfg@ICS.UCI.EDU writes:
    
    // The problem seems to be that g++ is forgetting about the implicitly
    // generated copy constructor c0::c0(c0&).

I think the problem has nothing to do with semantics...
    
    // Cfront 2.0 does not generate an error for this code.
    
    class c0 {
      int field_0;
    };
    
    class c0 global_object_1;
    class c0 global_object_2 (global_object_1);	/* gets erroneous error */

...but that the LR(1) parser cannot say whether this is an
initialized object declaration or a function declaration.  It
is documented in the "known limitations" section, if I remember
well. Cfromt gets it right because it uses heuristics or
backtracking or more context or other less agreeable technology.

By the way: somebody posted that he has written a C++/C yacc
grammar that solves virtually all ambiguities (it can parse in
C++ old style C headers), as long as you know at parse time
whether an identifier is a typedef name or not.

Is MDT interested in exploring the acquisition of this grammar?
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk