c++ code completion status report

[Richard Dale]

On Friday 04 January 2002 1:38 pm, ian reinhart geiser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Friday 04 January 2002 07:25, you wrote about Re: c++ code completion
>
> status report:
> > KDE Studio uses QDom for its class store - I did a brief comparison
> > between Studio and KDevelop and found that KDevelop was slightly faster
> > (Bernd also thought QDom would use more memory, but I didn't measure
> > that). Much more time was spent parsing than writing to the class store
> > in both IDE's. Would a be a good idea to profile gideon when it parses
> > the source files for a project? Then we would know whether the time is
> > going on lexical analyis, parsing or class store writes? John Birch did
> > some measurements on KDevelop 2.0 a while ago and found that the lexer
> > was taking most of the mill.
>
> Well QDOM allows you to break away from a solid data structure for you
> class store.  Python, Perl and C++ all handle objects differently, some
> have name spaces some do not... etc...  if() and switch() case statements
> would do the job but put you in hell very quickly.
The current class store is doing the job for multiple languages ok as far as I 
can see, because C++ is a 'superset' of everything else. C++ has multiple 
inheritance, class variables, instance variables etc etc.  if() and switch() 
statements aren't needed because we have different kparts for each language - 
'cppsupport', 'javasupport, 'phpsupport' etc. C++ code doesn't always have 
namespaces, so that code needs to be displayed in the class browser the same 
as a language where the code never has namespaces. If we were starting from 
scratch I think it might make sense to use QDom, but unless it does something 
better than what we already have I can't see any reason to switch.

> Ideally if we had a QDOM to store the class view and a KListView that would
> render it i think we would be about 75% if the way there.  You do not need
> XML to use a DOM, XML is just a convinent way to save and load a DOM.
Yes, KDE Studio doesn't use any XML, just QDom. But XML would be quite large 
if you wrote it out to disk for a persistant class store, and a lot larger 
than the original source files I should think. Is it quicker to read and 
parse XML files than the original C++, Java etc source files (I don't see why 
it should be)?

> 	well i was calling doxygen and then parsing the xml file. the
> entire process takes about 1.5 seconds for kdevelop's source.  really i see
> no use for a persistant class store information, the reason why i like XML
> is that it is fast to access the information from a DOM.  The hardest issue
> we have at this point is that a) Doxygen's XML has some "qwirks"  and b) it
> seems no-one here knows anything about what a DOM really does.
I don't know what machine you are running your test on, but this is about 4 
times faster than the measurements I took for the KDevelop or KDE Studio 
parsers on a 350 Mhz iMac. So a good reason to use the Doxygen parser might 
be speed, but I still don't see why we need to replace class store code that 
already works fine in KDevelop. Also I bet doxygen doesn't parse Objective-C, 
and I might have to redo objc parsing if we changed the cpp parser in 
cppsupport.

-- Richard