[Bug 58502] code completion doesn't work with namespace
Steven T. Hatton
hattons at globalsymmetry.com
Wed Feb 25 07:00:11 UTC 2004
-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the KDevelop-devel