[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison and C++
From: |
David Durham |
Subject: |
Re: Bison and C++ |
Date: |
Mon, 13 Aug 2001 09:45:59 -0500 |
>
> > * 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)
>
> Actually, since we want to output c++ classes, I don't see any good
> reason to write non pure parsers. Anybody sees something?
> Parser tables and other variables will of course become class members.
>
Ya.. the parser tables can be private class members, but they should be "static
const" data-members since they don't change and you should get better
performance
(being that they are only named in the class and not stored there)
>> * 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.
>
>Using c++ containers instead of all those c arrays sounds good to me.
>I have no idea of how this could change the parser performance, however.
>STL is usally very efficient, isn't it?
I don't know.. it's not a huge issue, but I'd just leave the allocation stuff
alone. The performance of just malloc/realloc should be just fine... However,
if we change it to an STL container, should we try to make it a "stack"... It's
got stack functionality built in... STL stack might NOT be a good idea if
the bison algorithm has to look forward and backward in the stack; I dunno if it
allows that...
-- Davy
Re: Bison and C++, Hans Aberg, 2001/08/11