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

[Douglas Schaefer <dschaefe@xxxxxxxxxx>]

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

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

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.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev