Re[2]: memory leaks

[hz kto]

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 <address@hidden>
To: hz kto <address@hidden>
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
>