New parser branch (Was: Dumping the source DOM?)
Steven T. Hatton
hattons at globalsymmetry.com
Thu Jul 14 18:52:03 UTC 2005
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.
More information about the KDevelop-devel