Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] To be exact or to be close enough

I'll let John and the gang answer the details, but as a motherhood statement, we should have good enough error handling in the parser to deal with as much information as we are given. I'm pretty sure that is the direction we are heading (or else you would hardly get an outline view at all).

Having said that, our objective will always be to be as exact as possible as we (the IBM team) have product requirements that drive us there. There are numerous strategies to get us there and all involve a lot of work. But as we're plugging away, we want to leave the best quality CDT feature set we can from release to release.

Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa, Ontario, Canada

Thomas Fletcher <ThomasF@xxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx

28/02/2004 06:07 PM

Please respond to

"'cdt-dev@xxxxxxxxxxx'" <cdt-dev@xxxxxxxxxxx>
[cdt-dev] To be exact or to be close enough


 I wanted to throw a couple of things out there for discussion.  Some
of this is covered in the scanner/indexer/search proposals, but I thought
that it would be worthwhile to have a bit of newsgroup discussion on the

Imagine I have a file testfile.c:
#include <inttypes.h>
int my_function(uint8_t a, struct mystruct *s) {
                return 0;
int main(int argc, char **argv) {
                return 0;

Assume that inttypes.h is supposed to declare a uint8_t, but it has
something inside of it that causes us not to interpret it properly.

As it stands today the user opens up the source in the editor, their
outline shows a fairly "complete" set of information but then when they
go to use features such as code completion (on my_function), open
declaration/open type on (on uint8_t) then what happens (failure) is
not consistant with the outline indicating that this is a function.

This can happen for a lot of different reasons, mostly going back to
"incomplete" configurations (defines and/or include paths not set). John,
Bogdan, Vlad, Sean and others are working hard to make sure that the
user knows about these problems and can fix them  However, here are some
things I'm wondering about:

- What happens when the error is in source you don't control (ie OS header
- Why should we have to re-index everytime a define or include path changes?

The first concern is just a practical issue.  Even with scanner/parser
coming along in 2.0, there may be compiler specific issues that are
and for the user, they may or may not care/be savy enough to be able to fix
What happens then?  Are they stuck?

The second concern comes up in my mind again and again.  Should we be
_everything_ and where ambiguous flag something as uncertain rather than
indexing the things we are absolutely sure about?  I realize that this is 1)
a significant challenge 2) closer to full text indexing which is already
by Eclipse 3) a problem we can solve many different ways.  I also get
if we start thinking about having "scanner configurations" (ie windows, QNX,
Linux, Cygwin etc) and how the user might flip between configurations
and on large projects the time spent scanning and indexing is going to be

Before I spend too much time really looking at these problems/issues I
I would get peoples feedback (ie "Oh yeah ... I'm already planning on
at that but here is where you could help" =;-)

Thomas ... rockin' w/ da CDT.
cdt-dev mailing list

Back to the top