c++ code completion status report
Richard_Dale at tipitina.demon.co.uk
Mon Jan 7 11:17:06 UTC 2002
On Sunday 06 January 2002 7:05 pm, Thomas Schilling wrote:
> > Is that 0.5 seconds going to grow when we are dealing with complex codes,
> > such as one that #include's a good collection of kde libraries?
> I'd say no. These files don't have to be reparsed since they
> don't change. And if they change parsing can be performed on saving
> or in the IDEs 'spare' time (say every 30s). One reason why it could slow
> down would be that the access on it's information is too slow. But that's
> some issue for the class store.
The only extra requirement I see for code completion is to be able to extract
variable declarations and put them in a symbol table. 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 store
parsing classes/method method declarations is sufficient. The existing less
detailed parse can find the methods that can be applied to an instance of a
particular class, which is all we need.
But the class store doesn't hold classes which aren't in the current project,
so extra parsing is needed for KDE and Qt classes which are parents of the
target code completion class. Perhaps that is just a matter of putting
include files found in #include directives through the class parser, and
saving the parsed details temporarily in the class store until code
completion is finished.
On Friday 04 January 2002 9:40 pm, Thomas Schilling wrote:
> ((MyClass)c)->member. // ...
> This is a typecast and should be recognized.
If the target code completion variable has something in brackets before it,
then assume it's a cast and use that type instead of the one looked up in the
symbol table. I see no need for complex expression evaluation/large bison
grammars to do that sort of thing. Surely we don't need to handle every
pathological case for code completion, just the forms that are most likely to
occur in practice?
> Other problem: These 168 shift/reduce actually shouldn't appear.
> I have 4 shift/reduce conflicts per alternative of e.g. "expr '+' expr"
> '+' is declared as follows: "%left '+'". In the BISON example this
> works without moaning. So what am I doing wrong?
Only that you are reinventing the wheel! There is absolutely nothing wrong
with becoming a bison expert, but there are already existing C++ grammars
that you could use. The point of open source development is to be able to
reuse other people's code, so that with relatively little work you can get a
lot done. Also by coordinating with other developers via mailing lists and
the cvs, you can learn things which you probably wouldn't if you just did
your own development in private.
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 plans.
For every C++ feature which gets added, I would like to add the equivalent
What if we would like to release a 'developer version' of gideon with KDE 3 to
attract other developers to contribute plugins? If cppsupport was completely
broken while the large grammar was being debugged, it would probably put
people off. Hence, my suggestion to use a new directory 'advancedcpp' for the
code completion C++ parser.
More information about the KDevelop-devel