c++ code completion status report
snuffeler at gmx.net
Mon Jan 7 13:47:05 UTC 2002
> The only extra requirement I see for code completion is to be able to
> variable declarations and put them in a symbol table.
That's part one. It has also be done for local variables - but only visible
It already exists (classparser.h/cpp) but has to be extended to parse
> Then, given an
> identifier name and scope, its type can be looked up. If the type is an
> instance of a class, the level of parsing used currently for the class
> parsing classes/method method declarations is sufficient. The existing
> detailed parse can find the methods that can be applied to an instance of
> particular class, which is all we need.
Part two. But as I wrote (some mail) before I hope to let CC be more
powerful. And having a grammar is much better to read and maintain
than some growing and growing C++ code file (and maybe even more
> I added Objective-C parsing to classparser.cpp, so I have an interest in
> cppsupport. If you intend to do large ambitious developments to that part,
> which might mean that it won't work for some months, it will affect my
> For every C++ feature which gets added, I would like to add the equivalent
> Objective-C feature.
> What if we would like to release a 'developer version' of gideon with KDE
> attract other developers to contribute plugins? If cppsupport was
> broken while the large grammar was being debugged, it would probably put
> people off. Hence, my suggestion to use a new directory 'advancedcpp' for
> code completion C++ parser.
Currently I'm changing ABSOLUTELY NOTHING. So nothing can brake.
Everything I've changed until now rests on my own PC. Since i've some of
these f***ed up WinModems I cannot use CVS.
I only have some experiments running to try out which approach is most
promising. I heard the cppsupport-part does run but is not 'perfect' so I'm
testing another, more complex approach.
Give me some days and I have some test case for you.
More information about the KDevelop-devel