Re: beta testing

[Hans Aberg]

At 23:43 +0100 2001/02/20, Philippe Bekaert wrote:
>If you change the union declaration in the bison script, my_type will
>not be automatically updated. This can be dangerous.
>
>Ideally, there should be a switch so bison does not generate the YYSTYPE
>union declaration in y.tab.c, but only in y.tab.h.

I do not use unions with C++: You could just as well make use of a derived
hierarchy, and have a few extra fields, if the items are not to big.

But the my other post.

>What about providing two base classes from which parser classes shall be
>derived:

Actually, I have absolutely no idea of what the final C++ support will look
like.

But, for my own use, I am writing on a formatter, a macro language, which
is similar to TeX (having definitions within definitions), except that it
outputs ASCII. One can also build environments beforehand, and then write
out sequences using macros. I use this to write out C++ code.

With such a formatter tool, it would be easy to write out the correct code
in whatever configuration, by changing a single formatting file.

>class PureBisonParser {
>public:
>  virtual void yyparse(void);
>  virtual void yyerror( ... );
>};
>
>class BisonParser: public PureBisonParser {
>public:
>  // all global variables of a non-pure parser come here
>};
>
>Someone writing a parser declares then
>
>class MyParser: public BisonParser {
>public:
>  void yyparse(void);
>};
>
>Or if you want, like me, the parser also to inherit from the scanner
>cless generated by flex, you get
>
>class MyParser: public BisonParser, public MyScanner {
>public:
>  ...
>};
>
>where MyScanner inherits from FlexLexer, for instance:

But before we know what will happen with Bison C++ support, your ideas are
as good as that of any. -- Please report here, if you succeed to implement
a working version. (The easiest way would be to have a single unchanging
header file, like the Flex FlexLexer.h header. In my opinion, though, it
would be better to write a correct header for each program that Bison
produces. Then, producing a corresponding FlexLexer.h header file would be
the first step.)

  Hans Aberg