c++ code completion status report

[Richard Dale]

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"
> while
> '+' 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 
Objective-C feature. 

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.

-- Richard