New parser branch (Was: Dumping the source DOM?)

[Steven T. Hatton]

On Thursday 14 July 2005 10:21, Roberto Raggi wrote:
> Hi Steven,
>
> On Wednesday 13 July 2005 20:16, Steven T. Hatton wrote:
> > There is another, more intrusive way which *may* have some advantages.
> > That is, build some of the actual XML DOM into the nodes of the CodeModel
> > (I think that's where it would go.) It's just an interface for nodes in a
>
> yeah I tried it. In the very early days I was using a QDomElement node for
> each AST node. Of course it wasn't a smart idea :-) 

Look at what I wrote again.  It's not exactly the same thing.  I was thinking 
about a partial implementation of the XML DOM node as part of the existing 
AST class.  Yes, the idea has something distasteful about it, but it's the 
only way, other than maintaining a shadow data structure, that I can see for 
providing XML DOM features.

It may be sufficient to simply use a tree walker for everything.  It would 
certainly be a shame to overcomplicate the AST with unnecessary clutter.

> So I switched to 
> std::auto_ptr<AST*> and this was another bad idea :-) because now we have a
> huge amount of call to the memory manager (== new/delete).. In KDevelop 4
> I'm using a memory pool. It improves a lot the performances because usually
> all the nodes in the AST have the same lifetime. You can take a look at the
> new KDevelop c++ parser.. or the code generated by the KDevelop parser
> generator http://trolls.troll.no/~rraggi/robe-pg-1.0.tar.gz

Thanks.  I hope to find time to look at this more closely.  I have been 
reading the code in the KDevelop-4 parser branch.
-- 
Regards,
Steven