c++ code completion status report

[Richard Dale]

On Monday 07 January 2002 3:11 pm, Daniel Engelschalt wrote:
> >With two C++ support directories, cppsupport and advancedcpp we could do
> >simple hacks in cppsupport like this, and use it to get the UI and widgets
> >prototyped and working. Then in advancedcpp, we could have the code
> >completion C++ parser stuff, which would do a better job in the long term,
> >even if it didn't work so well in the short term..
>
> ok, i agree to open another directory.
Yes, I was suggesting an extra directory 'advancedcpp' so we have two 
different parts for C++ support with different development time scales. On 
the other hand, why not have three? Until I'd thought about these issues it 
hadn't occurred to me that a C++ support part based on gcc 3.0.x 
preprocessor, tokenizer and grammar would be a really good idea. Fortunately 
there's no manager round here to tell us else what to do, and let us only try 
out one thing at once...

> but if i understand you right you want to use kde studio's method to see
> the ui is working ? well, it is working, just type "test(" at the beginning
> of an empty line and you see code hinting. very basic code completion with
> classes used in your project should also be possible. that's not the
> problem (just enable cc at parts/cppsupport/codecompletion.cpp - there is a
> #define at top of the code). but there are a lot of things (parsing
> cpp-file, finding correct scope, ...) which are in a very very early stage
> so i don't think we should make improvements to that code.
Ok - thanks I'll try that. 

> the only way i can see is to discuss what is "the best way for kdev" and
> then implementing it. as i said before, my goal is to give a new user a
> leading hand for easy things like QString x; x. or KApplication::
> so we can get experience / a feeling what problems (may) come up and _then_
> creating the perfect parser. that is what i tried with my parser.
> because it's one thing i've learned: what's your best program ?
>
> the next one.
How right that is! So maybe we need to speed up 'next one --> bugger that! 
reject it, move on again' development with some parallelism with extra dev 
directories :)

-- Richard