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

[Antoine Chavasse]

On 7/15/05, JeDi <jeroen.dierckx at gmail.com> wrote:
> On 7/15/05, Antoine Chavasse <a.chavasse at gmail.com> wrote:
> > On 7/15/05, JeDi <jeroen.dierckx at gmail.com> wrote:
> >
> > When refactoring, eclipse displays a window where you can check what
> > will be changed. You can select files/classes that are going to be
> > modified in a tree, and the changes are displayed using the difference
> > viewer.
> 
> That would be a very good aproach I think. In that way the user can
> see at forehand when the refactoring will fail, and can cancel /
> adjust it.
> 
> 
> > 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++.
> 
> Eclipse is indeed pretty advanced when it comes to code completion /
> refactoring for java. I haven't had a look at the code though, so I
> have no idea how it is implemented, and if it its code is readable
> enough to be of any help in kdevelop.
> 
> For C++ though, code completion and refactoring is a whole other
> story, as c++ is much harder to parse correctly, certainly in
> real-time (as this discussion has already proven).
> Correct me if I'm wrong, but doesn't Eclipse have a c++ plugin?
> Haven't used it yet, but that could indeed be a valuable resource.
> 

Yes, there is a C++ plugin (CDT). It's nowhere as mature as the java
stuff, though.
I think their approach is different to roberto's, in that they expect
to be able to find and parse all includes.
It means that every include path have to be configured. 
There's an option to auto-discover the paths that is specific to gcc,
but I had varying degrees of sucess with it.
I think it's supposed to work even if some includes are missing, but
actually, on a rather smallish project that I was working on, code
completion seldom ever worked in any case.

They are about to release CDT 3.0, which is available as a release
candidate, but I haven't used it, so I don't know how much they
improved all of this.

What I know about their parser, from what I've read on their
mailing-lists, is that in CDT 2.0, they had several different
specialized parsers (like one for code completion, one for refactoring
(they had a refactoring operation to rename classes and namespaces),
one for indexing symbols, etc.)

By the way, their symbol indexer was running as a background job, and
it had an irritating habit of reindexing everything from scratch
whenever you modified one file, so I ended up disabling it.

I believe that in 3.0, they replaced all these by a single, unified
parser, but I don't know much more about it.