Re: Flex 2.5.23 beta and C++

[Hans Aberg]

At 08:37 -0400 2002/10/23, W. L. Estes wrote:
>> But the standard is already here -- since 1998. So C++ isn't changing
>>anymore.
>
>I don't have any reason to believe that the next standard won't break
>something crucial and large about the current standard.

Are you writing code for eternity? :-)

-- I think there will no new C++ revision for the next five years at least,
possibly longer. And you probably wait a few years more further, in order
to let compliant compilers emerge, before writing official Flex code for
the new revision.

Plenty of time to write C++ code for the current version.

>> 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.
>
>What's going to happen is this:
>
>1: We'll get the current c++ interface so that it works (there's one
>bug that needs fixing.).

What is this bug? -- Apart from adding a few std::, I did not have to do
any changes.

>2: We'll make an official release.
>
>3: We'll change the c++ interface so that it's just a wrapper around
>the C scanner.

What is needed is essentially a class pure lexer, and I think, that should
be easily interfaceable with the corresponding class pure Bison parser, so
that the communication does not need to pass over any global (not in the
classes) variables. I didn't myself see any point of that Flex virtual
stuff.

I recall that the current FlexLexer.h file has some esoteric construction
where it can be read twice, but I do not recall what that was for. -- If
possible such stuff should be removed, I think.

Also, one should be able to wrap the stuff in a C++ namespace.

And one traditional Yacc/Lex style is to include the lexer sources into the
parser sources. -- Under C++, I use a more typical C/C++ header/source
style, where the lexer reads the Bison .h header and is compiled into a
separate compilation unit instead of being directly included by the parser
sources.

So that is what I immediately can recall.

  Hans Aberg