Re: memory leaks

[Laurence Finston]

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