Re: Bison with C++

[Hans Aberg]

At 12:16 +0100 2003/01/18, John Clinton wrote:
>I've been working to use the Bison version 1.875 to create
>a new parser as a C++ class.  I've been tweaking the lalr1.cc
>skeleton to try to accomplish my goals.  I thought I'd share
>these goals and see if you've been heading in a similar
>direction.  Then depending on my success I can soon share
>what I've accomplished.
>
>My primary goal is to have Bison generate a base class
>for the parser.  Then I will derive my own class from this
>base.

I use only the C++ class derivation stuff when it seems convenient or
necessary, for example when needing polymorphic classes (classes with
"virtual" pointers that should vary at runtime).

So instead of trying to do a Flex-like C++ base class, I am more inclined
at getting Bison to directly write a single class. And I do not seed any
need for a polymorphic base class.

This approach is very feasible with latest Bison which uses M4 for
post-processing. But I then need to tweak Bison to be able to write more
C++ code fields which then can be put into the right places.

The best thing would be if regular Bison was extended so that one in the .y
file could put say
  %code <name> {...}
creating a suitable M4 macro related to <name> with value {...}. Then one
can use that construct not only in C++, but in other languages which needs
to put in special places.

>Now my main issue is cleanly resolving the circular
>dependencies of the parser base and derived class'
>header files.

This removes any such problems.

>I happen to also be using Flex to generate a class for
>the scanner.  I chose to make the scanner be a nested class
>of the parser.  The derived parser class has an instance
>of this scanner and takes care of setting up the scanner so
>that any client of the parser merely gives a stream object
>to the parser and knows nothing of the scanner details.

The lexer needs also to be integrated in this. There are some discussions
of that in the Help-flex mailing list:
  address@hidden
  http://mail.gnu.org/mailman/listinfo/help-flex

>Another issue I have is some of the #define in the generated
>parser's header file that may be an issue if having multiple
>parser header files included from one module (.cpp file).

Since one can write pretty much the output one wants when using M4, I
worked with the approach to remove as many #define C pre-processor macros
as possible, replacing them with genuine C++ constructs.

So, summing up, mu C++ skeleton files cannot be used with current Bison
without some tweaking of the Bison sources. So I made some stuff that works
for me, but which at this point is probably not so useful to others.

  Hans Aberg