[cdt-dev] To be exact or to be close enough

[Thomas Fletcher <ThomasF@xxxxxxx>]

Folks,

  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
topics.

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) {
	<user_works_here>
	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
files)
- 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
extensions
coming along in 2.0, there may be compiler specific issues that are
encountered
and for the user, they may or may not care/be savy enough to be able to fix
it.
What happens then?  Are they stuck?

The second concern comes up in my mind again and again.  Should we be
indexing
_everything_ and where ambiguous flag something as uncertain rather than
only
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
provided
by Eclipse 3) a problem we can solve many different ways.  I also get
concerned
if we start thinking about having "scanner configurations" (ie windows, QNX,
VxWorks,
Linux, Cygwin etc) and how the user might flip between configurations
regularily
and on large projects the time spent scanning and indexing is going to be
nuts.

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

Thanks,
 Thomas ... rockin' w/ da CDT.