[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flex & Bison under C++

From: Hans Aberg
Subject: Re: Flex & Bison under C++
Date: Tue, 29 Oct 2002 22:49:49 +0100

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]