Re: Flex 2.5.23 beta and C++

[Hans Aberg]

At 14:13 -0400 2002/10/22, W. L. Estes wrote:
>> I think though that the feature is quite convenient though, once one has
>> gotten used to it, because all those standard functions do not interfere
>> with ones own code. For example, the following becomes possible:
>
>It may have uses, but it breaks code that has worked for over a
>decade. I don't have the energy to follow the c++ moving target. It's
>been changing for years now and maybe one of these centuries it will
>settle down onto something. Until then, my interest in it is going to
>be low-to-zero.

But the standard is already here -- since 1998. So C++ isn't changing anymore.

>> Well, the C++ standard is already here and fixed, it is formally called
>> ISO+IEC+14882-1998 and the ANSI version sells for $18 at ANSI. And there
>> will be no new revision for another couple of years.
>
>And then what? They'll break some more c++ code? If this is what flex
>has to look forward to, then I'm having a hard time seeing why it's
>worth the time of the flex maintainers to support c++ scanners.

What I mean is that the chaotic times that existed with C++ during the
1990'ies should not be anymore.

GCC is one of the more compliant C++ compilers.

It should not be a big problem to make code for the current C++ standard,
and you will not have to worry that it should become broken in a couple of
years.

>> I think that under C++, the only thing that makes sense is a class pure
>> lexer/parser: I am not sure there is any point in doing a fully function
>> pure parser, as one then, when needed can make a new class instantiation.
>
>I suspect you're right on this last. The c++ interface is suffering a
>great case of neglect at the moment. That neglect will be how things
>stay until at least after the official release, with a few exceptions.

If I figure out a better way to write the interface, I will report it here.

Highest on my working list is a class pure Flex/Bison combination.

Otherwise, I think I have found a pretty pleasing C++ syntax for the
Bison/Flex parser/lexer. Suppose the program produces data of type T, then
one say read from a file using:
    ifstream ifs("input.txt");
    T t;
    ifs >> t;
    if (!ifs) {
      std::cerr << "Could not read input file\n";
      return EXIT_FAILURE;
    }
    ...
In other words, the parser is tied to the type T in a way that one really
does not see it at all -- easy to use.

If one need to indicate the parser explicitly, one can use it as a
manipulator, instead writing
    ifstream ifs("input.txt");
    T t;
    parser p(...);
    ... // Set parser suitably.
    ifs >> p >> t;
    if (!ifs) ...
    ...

  Hans Aberg