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 _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison