[comp.lang.c++] Multiple parsers in C++?

sdm@cs.brown.edu (Scott Meyers) (03/27/91)

I'm writing an application that needs to use multiple lexers and parsers.
The ideal situation would be to use modified versions of lex and yacc so
that each lexer/parser was in its own class.  This is sort of done by
bison++, but it currently generates code that won't compile under anything
but g++ (it initializes data members inside the class declaration).  In
addition, there is no corresponding flex++, at least not that I know about,
so you're still stuck with a single lexer unless you go in and change
things by hand.  I also know about lex++/yacc++ that come with the Sun
compiler, but the (beta) versions that we have don't seem to generate
classes, i.e., they're just lex and yacc that generate C++ instead of C
(with no gain in flexibility).

What I want to be able to do is have files lexer1.l and parser1.y run
through a lex++/yacc++ yielding class parser1, which would have member
functions yylex and yyparse, while the files lexer2.l and parser2.y would
yield class parser2 with the same member function names.  Furthermore, I
want to be able to set up a makefile so the generation of these classes is
automatic -- I don't want to tweak things later by hand.  My source files
are the .l and .y files, and I really would like to keep it that way.

I hope I'm overlooking some obvious solution, and I'm hoping somebody will
tell me what it is.

Scott

-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."

lma@dayton.Stanford.EDU (Larry Augustin) (03/27/91)

sdm@cs.brown.edu (Scott Meyers) writes:

>I'm writing an application that needs to use multiple lexers and parsers.
>The ideal situation would be to use modified versions of lex and yacc so
>that each lexer/parser was in its own class.  This is sort of done by
>bison++, but it currently generates code that won't compile under anything
>but g++ (it initializes data members inside the class declaration).

Scott and I have exchanged some email on this subject, and I'm willing
to modify bison++ to work with other C++ compilers.  But I'm certainly
not a C++ guru, and I'd like to hear suggestions as to the best way to
generate the class headers.  (See my previous posting on the subject.)

So please send me suggestions for the best way to structure the
bison++ parser class.  I'll make the changes to bison++ and announce
the new version when it's available.

As for flex++, I personally just write scanners by hand.  But I'll
look at it.

As always, bison++ is available for anonymous ftp from
wilbur.stanford.edu.

Larry M. Augustin			ERL 414
lma@sierra.stanford.edu			Computer Systems Lab
lma@dayton.stanford.edu			Stanford University
(415) 723-9285				Stanford, CA 94305
-- 
Larry M. Augustin			   _         _      _     ____
					  | |	    | \    / |	 / __ \
ARPA: lma@sierra.stanford.edu		  | |	    |  \__/  |	| (__) |
BITNET: lma%sierra.stanford.edu@stanford  | |	    | |\  /| |	|  __  |
UUCP:...!ucbvax!sierra.stanford.edu!lma   | |____   | | \/ | |	| |  | |
AT&T: (415) 324-4929			  |______|  |_|    |_|	|_|  |_|