[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: beta testing
From: |
Hans Aberg |
Subject: |
Re: beta testing |
Date: |
Wed, 21 Feb 2001 10:46:26 +0100 |
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
- Re: beta testing, (continued)
Re: beta testing, Hans Aberg, 2001/02/20
Re: beta testing, Hans Aberg, 2001/02/21
Re: beta testing, Philippe Bekaert, 2001/02/21
Re: beta testing, Philippe Bekaert, 2001/02/21