New parser branch (Was: Dumping the source DOM?)

[Kuba Ober]

> By the way, for a java app, eclipse is pretty fast when it comes to
> code completion and on-the-fly parsing, and has implemented a lot of
> useful refactoring operations, so it might be a worthwhile source of
> inspiration, especialy as it's open-source, unlike visual assist -
> even tough it's java and not C++.

Java is an entirely different beast to parse/code complete than C++, mainly 
because the interfaces are well-defined. A class is a class, sits in its own 
group of files, and so on. C++ enforces no such relationship, and what's 
worse -- unless you know what preprocessor definitions to set, the headers 
are generally useless and often invalid by themselves. That seems like a 
minor thing, but is a major pain in the behind. Of course you could assume 
that C++ class headers need no special defines, but AFAIK this immediately 
breaks parsing of boost, stlport and several other template libraries that 
work around compiler bugs/differences.

Presumably, parsing of library headers could be done off-line (using even the 
same parser, but off-line) and then the parser would need to do full-blown 
preprocessing. And it would need to know what macros to ignore. Think Qt's 
QOBJECT and friends which you want to expand and process only optionally -- 
presumably only for people who debug bindings and stuff. Actually, one could 
think of a feature in which parts of the tree could be suppressed/enable 
during runtime, so that by default you wouldn't see all the stuff that 
QOBJECT expands to, but if you wanted to it could be reenabled and active 
immediately (in the class browser, for code completion, and so on).

So, while the overall idea is pretty simple, the details can easily kill a 
couple tens of hours to get right... (heh, Roberto would probably say to bump 
up the estimate to hundreds of hours :)

I'm actually thinking that using an external, off line parser, as long as it 
can emit the trees and catalogs that Roberto's code expects, would be quite 
useful for libraries. Then there could be several alternatives, e.g. existing 
r++ (is it called like that?), gccxml with whatever modifications one needs 
to emit Roberto-compatible data (tm). I could think of using tendra for the 
very same purpose, and so on. Myself, I find gcc code to be at the verge of 
unmaintainability, even though it's a darn decent compiler otherwise :(

On-line parsing and code completion are very different beasts, that's for 
sure.

Cheers, Kuba