c++ code completion status report

[Richard Dale]

On Friday 04 January 2002 6:41 pm, Thomas Schilling wrote:
> > I can't find any bison grammar in cppsupport. I see two flex grammars
> > with minor differences:
> >
> > tokenizer-cc.l  tokenizer.l
>
> No, the grammar was not yet put to public. These are the
> lexer used by the ClassParser by Jonas Nordin which
> was written in pure C++ and could only read classes.
>
> On my local machine I have now an (almost) complete
> lexer (i.e., these two are obsolete).
> The complete grammar also rests on my local machine.
> It's the one that Stroustrup wrote in his book on C++.
> It's just a superset of the actual language and hence not
> sufficient. There also is another grammar file to find at
> ftp://ftp.iecc.com/pub/file/c++grammar.tar.gz.
If you want to rewrite cppsupport, rather than just adding a couple of classes 
and a widget, how about starting another directory called 
'parts/advancedcpp' or similar? Then you can use the current sources in 
cppsupport as a starting point and start hacking, while the existing 
cppsupport part will carry on working until it can be replaced by 
'advancedcpp' in a month or two.

> > If you only want these tokens to be parsed in a 'more detailed' parse
>
> phase
>
> > why not have one flex grammar and use the 'REJECT' macro to reject these
> > tokens if doing the standard 'less detailed' parse for the class tree, as
> > oppposed to code completion?
>
> I think this won't suffice.
Umm.. why is that then? Do you think it is a good idea to have two sorts of 
parsing; one faster and less detailed with less tokens, and a second code 
completion style parsing with more tokens? If so, please explain how you 
think using REJECT is inappropriate for that. Maybe there should only be one 
mode of parsing which is more detailed than the present one as long as it 
didn't slow class browsing down.

>
> I vote FOR a persistant CS, for I don't know how much
> memory lot's of libraries would cost. And to end up this
> XML or DOM or whatever discussion: It may be possible
> to use XML or DOM as the communication layer between
> the front-end (tree of libraries) and the back-end (any sort
> of database or file). Otherwise I don't know what to use it
> for. Ain't this what XML want's to be - a framework for
> structured information interchange?
Have you considered the issues of the source files being newer than the saved 
class store on startup though? There would need to be code to check that a 
source file hadn't changed since the last persistant parse was saved.

> From: Richard Dale
>
> > The current class store is doing the job for multiple languages ok as far
>
> as I
>
> > can see, because C++ is a 'superset' of everything else. C++ has multiple
> > inheritance, class variables, instance variables etc etc.
>
> AFAIK it doesn't support 'using'-directives and 'using'-declarations.
> Furthermore I yet don't know how to handle preprocessing directives best.
I don't see any problems with the existing class store data structure to 
handle that sort of info - they sound more like parsing issues than class 
store issues.

> From: Andrea Aime
>
> > Ah, just as a sidenote, has someone considered
> > ANTLR? www.antlr.org. This parser builder has the
> > built-in ability to create the AST of the parsed sources...
> > seems to be an interesting alternative to flex/yacc...
>
> I think we should now settle one parser. Also this seems
> to be JAVA, ain't it?
You can write gideon plugins in Java combined with C++ - see the Java code in 
parts/javasupport. But probably not a good idea to have a java dependency 
with C++ support though. I think flex/bison are fine, as long as we use an 
existing working grammar (as you are doing I think).

-- Richard