[
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.
Fully
agree with that, especially the last statement. There is also a wealth of
information in the 2.0 plans for the scanner,parser and
search
and I guess I was looking more for a discussion of what facilities
might have to exist on top of that since there is going to
h ave to still be a significant
amount of "user configuration" required for "non-managed"
projects.
Thanks,
Thomas
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