Yes, if we included all local variables, I’d
afraid the index would be gigantic, and it would become difficult to tell local
variables with the same name apart.
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Schorn, Markus
Sent: Monday, June 04, 2007 3:47
AM
To: CDT General developers list.
Subject: RE: [cdt-dev] Bug 63927-
doubt
Erik,
the indexer does not contain information
about local variables, nevertheless
the rename refactoring will figure out
name-conflicts even with local variables,
just give it a try!
Markus.
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Erik Nilsson
Sent: Montag, 04. Juni 2007 09:17
To: CDT General developers list.
Subject: Re: [cdt-dev] Bug 63927-
doubt
Hehe, you might be right.
It´s just that I think I thought it was broken (or just not fully working
because of the indexer) and so always fell back to using the normal text
search. You know, thinking that that will sort itself out sooner or later ;)
By the way, does that mean that the indexer doesn't contain information about
local variables at all?
In the above example, if I tried to use refactoring to rename highVal to inp
(for whatever reason), would the refactoring tool be able to recognize the
naming conflict?
I'll try to attach it to the bug mentioned if it seems appropriate.
//Erik
2007/6/4, Doug Schaefer <DSchaefer@xxxxxxx>:
Given that this is how the CDT has always worked, and that
few people have complained about it, I'll dispute the statement that "behavior
like the one above will actually make most people believe that CDT is
broken".
Thanks for the feedback, though, and please make sure you
capture it in a bugzilla entry for future reference.
First impression: Oh!
I think I understand why this has to be this way from a technical point of
view. But from a users perspective it makes no sense. Maybe if you at least
changed the wording of the C/C++ search dialog box so it makes clear that it
only searches for public variables it would seem a bit better. But not
entirely, because chances are that you don't actually want that behaviour.
Maybe you could add a check box to automatically do a text search of C and C++
source files after the initial index search is done. But that makes the meaning
of the C/C++-search function even cloudier. Perhaps if you called it
"C/C++-index search" people would at least have chance to figure out
what that dialog actually does.
Actually, perhaps the Index just isn't the best tool for doing a good C/C++
search function. I would naivley think the procedure would be something like:
1) Text search all interesting files (.c .cpp whatnot) for word occurence 2)
parse the files matching to figure out what that word actually is in terms of
C/C++ 3) filter accoring to user preferences, variables, methods etc 4) ... 5)
profit
I think the most important thing is that you must be able to depend on the
search function, behaviour like the one above will actually make most people
(everyone not very accustomed with the inner workings of CDT) believe that CDT
is broken.
Regards,
Erik Nilsson
2007/6/1,
Doug Schaefer <DSchaefer@xxxxxxx
>:
The index only captures global variables that can be
referenced between files. Capturing every variable everywhere would really slow
things down. You can always use Text search, while slower, will find all text.
#include <iostream>
int highVal;
// ** (A) **
int
main(int
argc, char
**argv) {
std::cout << "\n";
char inp[8]; // ** (B) **
std::cin >> inp; // ** (C) **
}
In the
C/C++ index view only highVal and main are seen. inp is not seen
in the
index. Hence C/C++ search of inp is not yielding any results.
Please
let me know if it is OK for the indexer not to index inp.
Thanks,
Ravi
Extn: 2751
Mobile:9886432301
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|