[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison and C++
Re: Bison and C++
Fri, 10 Aug 2001 20:46:36 +0200
> So, please, go ahead, any proposals,
> suggestions, or comments are welcome.
* use enums instead of #define's, they don't polute the global namespace.
* allow to build easier pure parsers, by moving the currently global
variables into a parser class, this one can be instanced how often the
programmer wants, or until memory exceededs :o)
* I guess it is possible to create the parser as a template, instead of the
#define YYSTYPE as it is used in c.
* Another brainstorm idea only, I don't know if it's too good, the parser
stack could be realized by some more convinient c classes instead of the
reallocation stuff inside of yyparse, like vector<> in example, but I don't
think it will bring any performance, actually guess it would loose some.
* add #ifndef __PARSER_GRAMMAR_H__, #define __PARSER_GRAMMAR_H__, #endif to
the generated header files, in example for a file called grammar.y,
grammar.yy, grammar.yxx or however you call the c++ extensions. (little small
voice cawing: grammar.cc.y :). Eithercase differently if possible, so one can
use two bison parsers in one project. I had once to "double use" one parser
as actually two parsers, since an application will fail miserably at linking
stage if it has two different bison parsers.
* There are many more languages, beside C / C++. It would be cool if
there would be some generic "parser template description" file, telling bison
how to create things. So projects with alternative languages just would have
to deliver their parser template specifcation file with their source code,
and not a whole modified version of bison, which users have to configure,
make, make install. I know I can come with my own "bison.simple" version, but
there are some things bison generates where it implies the result is C. Like
the #define statements, the look of the actions, the headerfiles and the type
* Another brainstorm idea, maybe it would be nice to cleanly structure bison
more. Having a frontend that just generates the LALR parser tables, and the
backend that actually builds the parser code. So one part it's just a general
LALR table generator, and the other part is a simple code generator.
Hope you'll find some of the piled idea's fruitful, I'm currently out of
Re: Bison and C++, Hans Aberg, 2001/08/11
- Bison and C++, robert anisko, 2001/08/10
- Re: Bison and C++,
Axel Kittenberger <=
- Re: Bison and C++, Robert Anisko, 2001/08/10
- Re: Bison and C++, Hans Aberg, 2001/08/11
- Re: Bison and C++, David Durham, 2001/08/13
- Re: Bison and C++, Hans Aberg, 2001/08/13
- Re: Bison and C++, Robert Anisko, 2001/08/13
- Re: Bison and C++, Hans Aberg, 2001/08/14