c++ code completion status report
Richard_Dale at tipitina.demon.co.uk
Mon Jan 7 18:46:02 UTC 2002
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
More information about the KDevelop-devel