Re: C++, %glr-parser and non-POD semantic values

[Frans Englich]

On Tuesday 29 May 2007 12:02, Tim Van Holder wrote:
> Frans Englich wrote:
> > Hello,
> >
> > What direction do you recommend me to take?
> >
> > I like the C skeleton because it's simple and it doesn't have
> > dependencies on the STL, which is a no go for me, unfortunately. So, I
> > simply need a parser(GLR, or non GLR, if necessary) that can have non-POD
> > semantic values, in a safe manner.
>
> The easiest is to simply use a pointer to your class as YYSTYPE; the
> lexer can then construct an object if there is a relevant semantic
> value, or set it to 0 to indicate there isn't (a distinction that can
> be useful in some cases).
> This way, you can use the C skeleton without problems, and the GLR
> skeleton should work too.

> Of course, without the use of bison destructors and/or error handling
> code you can have leaks using this approach

Yes, that's the big problem. And destructors won't do it for me, due to 
exceptions.

> (in my case, my YYSTYPE is 
> a pointer to an AST node, and the constructor of such nodes adds the
> node to a global 'orphaned_nodes' list, from which it is removed when
> it's added to a tree, so it's easy to detect & clean up 'leaked' nodes).

Yes, that would work I guess. A custom memory pool/handler. It seems like it 
would be a "custom token value stack."

Though, to me it seems it would turn out verbose since Bison can't help you 
with the semantic types. For instance, currently my code reads '$3 == "foo"', 
where the type of $3 has been set to the string class member by Bison due to 
a %type declaration. With a pointer, it would turn into '$3->stringMember == 
"foo"'. This is a significant amount of work/code, my grammar file is about 
3000 lines long..

But it does indeed seem like it would work, at least.


Cheers,

                Frans