KDE/kdevelop/languages/cpp/cppduchain

[Hamish Rodda]

On Tue, 17 Jun 2008 10:29:08 pm David Nolden wrote:
> Am Dienstag, 17. Juni 2008 13:41:56 schrieb Hamish Rodda:
> > I'm hoping that this process will make the code less fragile, and
> > probably expose a few bugs along the way.  For example, of the various
> > openContext varieties in c++, some call editor->findRange, and some call
> > editor-
> >
> > >findRangeForContext; shouldn't they all be calling findRangeForContext?
>
> Hmm yep that's probably true, unless that hack had a special reason.

Ok, I'll change it locally and use it for a while to see if I notice any 
regressions.

> > Refactoring will also make the code easier to understand, and to document
> > for those working on the code.
>
> I agree, I just fear that it will throw my effort to make the
> parsing "reliable" back a bit, because the count of bugs in C++ support is
> increased again instead of sinking constantly.

Yes, well this is why I reviewed each shared method line-by-line to try to 
avoid any regressions, so hopefully there shouldn't be any (at least not 
many).

> > Fixing bugs with the code should not be much harder than if all of the
> > logic were in the one class as currently, in fact I think it is even a
> > bit more object-oriented now given that the visitors are a bit more
> > separated from the parser state.
>
> It just won't be easily possible to fix problems in the C++ support without
> possibly breaking other languages.

Please, break away, and if you're finding that you need to add c++ specifics 
to the generic builder, it's maybe a sign that I've gone overboard in 
generalising, or that the code needs a refactor, so just let me know.

<snip>

> > (Are you sure that it's not a
> > premature optimisation to do that, because most likely the persistent
> > duchain store will make 90-99% of parsing happen only on rare occasions,
> > right?)
>
> I'd like to make use-building the default at some point, so it would be
> senseless having that additional run through the complete AST. And we will
> always be doing a lot of parsing, don't worry about that. For example when
> you change a header, you will have to reparse all the files that
> recursively include it, if the change was significant.

Sure, but how can you find definitions that aren't created yet? or will you 
save all uses, then search for their definitions in a post-processing run?

> Anyway, in general I agree with you that generic code should be shared, but
> there is just cases where generalization makes everything more complicated
> then bringing a benefit(Having worked a lot on the DUChain I know what I'm
> talking about). Even the splitting between Context-/ Type-/ and
> Declaration-builder has sometimes been problematic, because they are not
> independent, and the way they interact is hard to track. 

I'm thinking about doing some more documenting to help this.

> Well, that's 
> enough of whining for now. Let's better try fixing kdevelop. :)

:)

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20080618/33bf84be/attachment.sig>