[Bug 58502] code completion doesn't work with namespace

Steven T. Hatton hattons at globalsymmetry.com
Wed Feb 25 07:00:11 UTC 2004

Hash: SHA1

On Tuesday 24 February 2004 05:35 am, Roberto Raggi wrote:

> you can retrieve the full qualified name using the method
> ClassModel::scope() and the ::name() of of your CodeModelitem..

I have to look more closely at the code, and documentation to understand how 
all this works.  I'm not clear on what data object actually holds the 
representation of the libraries.  You had mentioned that some component 
required too much overhead.  I'm not sure if that is the QDom I saw while 
looking through the code or not.  

Here's what I was thinking about.   You probably know about locate already.  
I'm going to describe the relevant aspects to give context to what follows. 
On my SuSE Linux box there is a locatedb that gets updated every night.  It 
builds a list of every file on my harddrive except the ones which are 
explicitly excluded.  I use the `locate' command to query the database. The 
response is usually very fast. When I do a locate CppSupport, I get 


The format of the database is described here in the documentation:

For a better example of how that might be useful in handling the code 
completion database take a look at the file listing for KDevelop:


If I want the autotools subtree, I simply grep for ^buildtools/autotools/

If I understand correctly, the entire corpus of accessible C++ header files 
could be (and perhaps is) represented by fully qualifying sequences similar 
to a file system's directory and file names.  As I understand what you said 
above, I can get a representation of the current scope  of the edit cursor in 
such a format.  I believe that representation could be used in a way similar 
to the filter passed to grep in the above example.

I know what I have described so far is not sufficient to solve the code 
completion scoping problem, but I believe it presents an approach which, in 
principle, would work.  I suspect whatever method you have used, it is 
logically isomorphic to this approach, though it may appear to be very 

> of if you're using Catalog you have to call Tag::path().. all these
> informations are already used in CppSupport part.

I took a look at the API documentation, and some of the code.  Understanding 
what's actually taking place will require a good deal of effort on my part.  
I believe it is a bit rude of me to present my thoughts without taking the 
time to understand what you have already done.  I did so because the 
essential part might be something useful to you which you were unaware of.  
That is, the locatedb structure.

> I don't think it is a good idea to use compression.. it is too slow.. the
> best way to solve the problem is to use a Storage Pool, and not a call to
> the memory management(i.e new/delete) for each new AST node.

That's how Mathematica achieves great speed.  

As regards compression, the kind used by the locatedb might have no impact on 
performance, or even improve it.  I used to be of the opinion that 
compression meant slowing things down, but I was presented with 
counterexamples which convinced me that is not always the case.

> ciao robe

Version: GnuPG v1.2.2 (GNU/Linux)


More information about the KDevelop-devel mailing list