If I have a list like this wouldn't I run into the problem when,
a parent node deletes some child nodes, then when I come across
this child in the list, I will crash since it has been deleted already?
Ugrading to 2.0 is not easy, since different parts of software are using
Bison, which is slightly modified too, and I have no knowledge whether
it is going to impact those parts. It is an option, of course, that
I will investigate.
thanks,
Alex
-----Original Message-----
From: Laurence Finston <[EMAIL PROTECTED]>
To: hz kto <[EMAIL PROTECTED]>
Date: Tue, 7 Jun 2005 13:03:05 +0200 (MEST)
Subject: Re: memory leaks
>
> On Tue, 7 Jun 2005, hz kto wrote:
>
> >
> > I am using C++ with bison 1.25, so it does not have %destructor. I cannot
> > rely on
> > garbage collecting, so I have to free everything myself.
> > Also I do not have common base class for all parse tree nodes (so I can't
> > have
> > a storage for all parse tree nodes, and then call virtual destructor for
> > everybody in case of error), and I cannot create
> > such class, because objects stored in the parse tree are from different
> > "groups"
> > so to speak, that are not supposed to be linked together.
>
> There's no need to create a common base class for the objects for which
> you allocate heap storage in your parser actions.
> These are not parse tree nodes. You could use something
> like this:
>
> struct
> Object_Type
> {
> unsigned short type;
> void* object;
> Object_Type* next;
> }
>
> Object_Type curr_object = new Object_Type;
> curr_object->type = 0;
> curr_object->object = 0;
> curr_object->next = 0;
>
> When you allocate an objects in a parser action, you would
> do the following:
>
> Foo* new_foo = new Foo;
> Object_Type* new_object = new Object_Type;
>
> new_object->type = FOO_TYPE;
> new_object->object = static_cast<void*>(new_foo);
>
> new_object->next = curr_object;
> curr_object = new_object;
>
> If 'yyparse()' exits because of a syntax error, you can step through
> the linked list of 'Object_Types' starting at 'curr_object', cast
> the 'object' pointers to the proper type based on 'type', and delete
> them. When 'next == 0', you've reached the end of the list.
>
> Depending on circumstances, it might be advantageous for 'object'
> to refer to a 'Foo**' rather than a 'Foo*'.
>
> I use a more elaborate approach in GNU 3DLDF, and its purpose is
> not primarily error recovery, but this is the basic idea. I've
> discussed my approach previously on this list. In my sources,
> the type 'Id_Map_Entry_Node' corresponds to 'Object_Type*' in
> the example above, in case you feel like looking this up.
>
> > Is it hard to incorporate destructor functionality from 2.0 into 1.25? What
> > kind
> > of changes would that require?
>
> Why not just upgrade to 2.0? However, the approach outlined above is
> not compatible with the use of '%destructor'.
>
> Laurence Finston
> http://www.gnu.org/software/3dldf/LDF.html
>
_______________________________________________
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
