Base classes declaration under DUChains

Hamish Rodda rodda at kde.org
Fri Mar 13 22:29:56 UTC 2009


On Saturday 14 March 2009 08:05:23 David Nolden wrote:
> Am Freitag 13 März 2009 21:46:03 schrieb Lior Mualem:
> > Hi,
> > I'm trying to display a list of base classes within the class browser and
> > I see that the base classes list is Cpp specific - in
> > Cpp::ClassDeclaration thus it exists only within the KDevelop project and
> > not under the kdevplatform project (which is where the class browser
> > should be).
>
> There is a slight duplication in this regard. You can also get to the base
> classes through the context structure:
> Declaration* declaration = Declaration of a class
> foreach(DUContext::Import import, declaration->internalContext()-
>
> >importedParentContext())
>
>  if(import.context()->kind() == DUContext::Class)
> 	then import.context()->owner() is the declaration of a base-class of
> declaration
>
> Notice that you always have to do a null-pointer check, for all the
> pointers treated in that code.
>
> > Is there a reason why a list of base classes shouldn't reside within
> > something that's defined in kdevplatform (atleast an interface class)?
>
> I think we were thinking about moving Cpp::ClassDeclaration to
> kdevplatform, but haven't come to it yet.

That would be good, i had to duplicate much of it for java.

<snip>

> > P.S: Is there developer documentation that explains the idea behind the
> > different classes and their relations with regards to DUChains?
>
> I think Hamish Rodda has written some documentation, I don't know where it
> can be found though.

http://api.kde.org/4.x-api/kdevplatform-
apidocs/language/duchain/html/index.html

> So how far have you come with the class-browser? At some point I might peek
> at what you've done. The most important thing is that it should be fast.
> You should remember that whenever you call
> KDevelop::IndexedDeclaration::declaration(), it may mean a complete file
> has to be loaded from disk. For that reason, the actual duchain
> declarations or contexts should only be used for displaying detailed
> information that is actually visible on the screen. All other content of
> the class-browser should use the simple representation from
> KDevelop::CodeModel(It is maybe a bit too simple, but with some tricks, it
> can be used to build a hierarchy)

I fixed the code browser a few days ago, it works pretty well now except that 
for some reason the forward declarations are still displayed even though I've 
filtered out any CodeModel::ForwardDeclarations.

Cheers,
Hamish.




More information about the KDevelop-devel mailing list