C++ Parsers for KDevelop (kinda long)

[Daniel Berlin]

>>>>> "RD" == Richard Dale <Richard_Dale at tipitina.demon.co.uk> writes:

   RD> how easy it would be to add grammars for additional languages - such
   RD> as Java or Perl. Is the OpenC++ parser code easy to adapt to parse
   RD> other languages?

No.
But no C++ parser is.
Even Exuberant CTags (which is what i actually meant, not regular ctags),
which supports Java,C++,C and Eiffel, handles this by saying what keywords
are valid for what language when they are close enough languages to use the
same parser (Java,C,C++), and using seperate parsers for the other languages
(Eiffel in this case).

Why?
Because you are missing a very important point i didn't make (:P).
C++ is hard to parse.
Java and Eiffel aren't.
C is kinda hard, nowhere near as annoying as C++, however.

Most other languages fall in the "Java and Eiffel" category of being
relatively straightforward to write parsers for.
C++ is very very evil to parse fully. which is pretty much what you need for
code completion.


   RD> I'm not an expert in C++, but are there any major problems with the
   RD> current parser?

There are some, but it's generally a nice parser.
   RD> Code under development often doesn't quite parse
   RD> anyway, so to me an IDE which is 'over fussy' could be
   RD> counter-productive.
Well, openC++ continues on errors until a certain number, by skipping to
right after the next "has to be valid" token (";" in most cases).
I disabled the error limit, and it could happily parse files with errors in
them, and you only got wrong info where the error was.
Flex (Doc++/Doxygen) isn't exactly known for it's error recovery. 
Antlr (none as of yet) is.

In fact, C++ parsers with error recovery of some kind, can be used to
highlight errors as you type.

That's another reason speed becomes so important. If you can reparse every
second at minimal cost, you can do very very cool things.

   RD> -- Richard