c++ code completion status report

[Victor Röder]

Hi!

Richard Dale:
> But why do we need a persistant class store anyway, using xml or
> otherwise? On 
> startup, will it determine which source files have changed since the class
> 
> store was last written to, and only parse those?

When you want to do code completion you need the source informations of the
used library/-ies (e.g. Qt). And these informations have to be *preparsed*
and stored so that cc is fast. Another advantage of a persistant class store is
a the "high-speed" project loading.
Example Gideon: Loading the KDevelop2 project with parsing takes 7s. Loading
the source informations from an binary file takes only 1s.
At the moment on start up the class store file is read and on projectClose()
the file is written to the again :-).


Ian Reinhard Geiser:
> 	well i was calling doxygen and then parsing the xml file. the
> entire process takes about 1.5 seconds for kdevelop's source. 

1.5s to parse the whole KDevelop sources? Gideon's/KDevelop2's needs about
7s on a 650 Duron.

> 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. 

See above.

> 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.

You can make us know ;-).

> 	The other approach is to look at doxygen's souce and just use the data 
> structure he is using there internally.  I must warn you though it is a
> two 
> drink minimum to look at that code :P

I have expected that. That's why I think a parser written by the *team*
could more fill up the requirements of Gideon.

> 	I give my sympathies to anyone here who wishes to write there own parser.

May the force be with us! ;-P

> 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.

Hmmm, did you have look at the structure of the class store? I don't think
it's bad. I think it's very useful, also for other languages. For the class
store it's not interesting *how* a language handles objects - only *if* a
language could deal with objects.

> 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.

As I said before, it's a "QDataStream serialized binary file" from which the
project source informations were read. And I think a XML-based class store
will not be fast enough.
Imagine: We will need the preparsed PHP functions (at moment stored in a
text file), the Qt, the kdelibs and maybe STL, GTK. An other libs might come. I
don't think that XML is the right way to go...

Bye,
Victor

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