RE: C++ lexer (GCC 3.1.1) requires knowledge of other C dialects

["Gary Funck" <gary at intrepid dot com>]

> -----Original Message-----
> From: Neil Booth [mailto:neil@daikokuya.co.uk]
> Sent: Wednesday, July 31, 2002 3:09 PM
> To: Gary Funck
> Cc: Gcc Mailing List
> Subject: Re: C++ lexer (GCC 3.1.1) requires knowledge of other C
> dialects
>
>
> Gary Funck wrote:-
>
> > The rid_to_yy table requires an entry for each reserved word in
> *all* supported
> > C dialects, and the table is ordered by increasing RID_* values.  A few
> > observations:
> >
> > 1) This dependency on other languages makes it more difficult
> to add a new
> > dialect and violates modularity.
>
> Agreed.  Any patch that might improve this without sacrificing
> performance is welcome.  However, I suspect that you might discover why
> things are done the way they are if you attempt such a patch.
>

I think that adding a reserved_id.def file which contained essentially a
union of the info. required by C, C++, and Objective-C (and other dialects)
wouldn't be too difficult to construct, and wouldn't impact performeance,
but I haven't looked into the details.

> We're slowly working on combining the C/C++/ObjC front ends into one
> mahousive front end that handles them all.

Will this new front-end still be YACC (bison) based? I've seen and heard
about an effort to build a hand-crafted recursive descent parser. Although
there may be some advantages to such an approach, I can see where adding new
dialects of C might become problematic with such an approach - it may be
difficult to verify that new language constructs do not break the parser by
introducing the need for new look-ahead sets, etc. The advantage of using an
automated parser genreator (like YACC, PCCTS, JYACC, etc) is that these
programs can determine if (and where) the grammar is ambiguous, and will
automatically generate the required (and correct) look-ahead sets.