Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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.

Back to the top