Re: Flex & Bison under C++

[Hans Aberg]

At 14:28 -0500 2002/10/29, John Millaway wrote:
>Why do you want a C++ scanner? What feature does the reentrant C
>scanner lack?

The main objective is to have a scanner that compiles correctly under C++
so that one can use C++ actions. This merely causes the code to use
std::size_t instead of size_t, etc.

The next objective is for convenience to wrap this up in a class pure
interface using namespaces, so it fits together with all the other code one
writes in C++. That is, the Bison parser and the stuff that computes the
actions.

When using Bison, it is imperative to use a correctly written C++ container
(like std::vector, etc) in the push-down automaton stack, so that C++
destructors are properly invoked.

So in the Bison parser, it is more important to have a special C++ version.

The use of an enum for the token_type is has the advantage of wrapping
those names up in a C++ namespace. Some of these changes are in Bison also
motivated by the need of being able to extend/diminish the range of these
types, depending on circumstances.

Such factors then pulls the need and want for a Bison parser C++ class
which is class pure. And if one would want to use Flex, one wants it to
conveniently interface Bison.

If this is done properly, one can under C++ hide away all the lexer/parser
stuff  to the user. Suppose my lexer/parser produces data of type T, then I
can make it look as for example
    std::ifstream ifs("input.txt");
    T t;
    ifs >> t;  // Parse to read the t value.
    if (!ifs)  error
    ...
This is pure in the sense that different such invokations cannot clash.

This is then very convenient, because one really does not need to know
anything about the parser/lexer when using it: Use it to read data behaving
as any other type of data.

I haven't looked at the %option reentrant much:

I can immediately note though that it defines a lot of macros. Under C++,
one does not want to have a lot of macros, as the names can be wrapped up
in a C++ namespace.

Also, my parser/lexer combination uses variables that are global to the
lexer, but local to the parser. So I would still want to put that stuff in
a class (otherwise the stuff above would not be pure): The lexer class
seems to be the most logical place, as these are variables that the parser
does not need.

  Hans Aberg