Re: Bison and C++

[David Durham]

> 
> > * 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