[antlr-interest] Re: Limits of tree generation (C++)

Tiller, Michael (M.M.) mtiller at ford.com
Thu Oct 9 07:09:14 PDT 2003


> From: Ric Klaren [mailto:klaren at cs.utwente.nl]
> Sent: Thursday, October 09, 2003 6:43 AM
> To: antlr-interest at yahoogroups.com
> Subject: Re: [antlr-interest] Re: Limits of tree generation (C++)
> 
> 
> On Thu, Oct 09, 2003 at 09:58:08AM -0000, marcschellens wrote:
> > The next stage of processing that tree knows only to read
> > the first node.
> > As I understood, the nodes are reference counted.
> > Isn't it therefore more effective to keep it like it is,
> > or is there a caveeat?
> 
> You'll have the same node in the tree in multiple places, usually this will
> give problems. E.g. at a later stage you will forget about it maybe switch
> to some custom AST with extra info and get bitten by it, or you add a child
> to it at a later stage and see it appear in two places. The sky's the limit
> as Murphy said...

So then can someone remind me why reference counting is even used?  Wouldn't it be better to make each node solely responsible for its children (i.e. the children are deleted either when they are removed or when the parent is destroyed).  It just seems that a different memory manage/garbage collection scheme would map much better given that nodes cannot be shared.

> dupTree is the right thing here I guess (look for it in ASTFactory.hpp) if
> you know for sure that there's only one node a simple clone might do the
> trick as well.

I would point out that I created my own stand-alone implementation.  I found no reason for ASTFactory to be involved in this process.  This is much more convenient because, as I recall, dupTree is a non-static method of ASTFactory.  Having to instantiate an ASTFactory just to call dupTree is just too inconvenient (and totally unnecessary).

Just some things to keep in mind for ANTLR 3.

> Cheers,
> 
> Ric

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




More information about the antlr-interest mailing list