Re: [Fwd: question about error handling]

[Axel Kittenberger]

Hi,

In my little project (to see in the signature :) I'm doing principally the
same, having a base node class, and deriving all kind of special tree nodes
from it.

Regarding memory managment, might be worth a while taking a deeper look
about using a garbadge collector. As compiler programmer it saves you completly
from worries about freeing objects. You donnot need to paranoicly copy
objects, in cases where you donnot know exactly who is responsible for freeing 
the
objects, thus may even result in a better performance than tradional memory
management. And as compilers are usually everything but realtime, the lost
milliseconds when the collector pops in do not hurt anywhere.

> As far as cleaning up memory upon parse errors... Here's what I did.. 
> I'm using C++, but I'm sure something like this could be done with C if
> you try really really hard ;)
> 
> Anyway, all my parse tree nodes are C++ classes and they are all derived
> >from a base class.  This base class's constructor adds the this pointer
> to a static data-member list of parse tree node pointers.  And the
> virtual destructor of this base class removes itself from the list.
> Then if I have an error, then I just delete all the pointers in this
> list.  
> 
> Also, I once used to be really careful and in the destructor of every
> parse tree node I would be sure to also delete any child nodes.
> Otherwise I would have a mem leak... I've seens said 'screw that, I'll
> just maintain this list of pointers even after I've successfully parsed
> and use it to clean up'... 
> 
> So you see, I've just made a fail safe way of never forgetting to
> cleanup a single parse tree node.  Everytime a parse tree node is
> allocated, it adds itself to this list.  And, everytime I delete a parse
> tree node, it removes itself from this list... 
> 
> Does this help?
> 
> --Davy
> 
> On 07 Jun 2001 19:43:08 +0200, Hans Aberg wrote:
> > At 11:13 -0400 2001/06/07, ashish sehgal wrote:
> > >When the bison generated parser encounters an error in the input
> > >expression and there is no error recovery grammar then the forrest of
> > >linked up structures that may have been created as part of parsing need
> > >to be cleaned up else every wrong input stream causes this memory to be
> > >allocated and not get deleted at all when the parser is working as part
> > >of another thread.
> > 
> > Have you run out of punctuation marks at your company? -- They surely
> help
> > the parsing. :-)
> > 
> > But sure, if you can't take memory leaks, then garbage must somehow be
> > collected.
> > 
> > >Is there some standard functionality available to do some cleanup
> > >associated with the values associated with bison's internal stack ??
> for
> > >instance something that lets you iterate over all the
> > >values in the stack and delete them.
> > 
> > I use C++ which does that cleanup automatically (if all used memory
> > management is wrapped up in automatic objects). So I do not know.
> > 
> > But I am not GNU, just a reader of this list. -- Perhaps somebody else
> can
> > give a better answer.
> > 
> >   Hans Aberg
> > 
> > 
> > 
> > _______________________________________________
> > Help-bison mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/help-bison
> 
> 
> _______________________________________________
> Help-bison mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/help-bison
> 

-- 
...
<D>  http://dtone.sourceforge.net
´´´ 

Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a

--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net