| T O P I C R E V I E W |
| talamar |
Posted - Jun 15 2011 : 5:39:27 PM
The problem is the following.
I create new solution, add two projects to, using the Visual Studio "Add new Project" wizard, and make some slight modifications to the code.
Resulting code of both projects (for instance the projects are named "Console1" and "Console2") is identical:
#include "stdafx.h"
void foo() {}
int _tmain(int argc, _TCHAR* argv[])
{
foo();
return 0;
}
Then I need to rename the "foo" function in project "Console1" (not in "Console2"!).
I place caret on "foo" at line 2 of .cpp file, which belongs to the project "Console1", and select "Refactor->Rename".
As a result, I get 4 references:
1) two references within this project ("Console1");
2) two within other project ("Console2").
Here the references from "Console1" are correct, because the foo() function defined in project "Console1" is visible at both points (lines 2 and 5) of the file belonging to "Console1".
Along with that, the references from project "Console2" are found incorrectly, because the foo() function from project "Console2" is NOT the foo() from project "Console1".
"foo" symbols from project "Console2" are completely unrelated to the "foo" symbols from project "Console1" and thus must not be listed.
The same may be said about any other function or global variable which has the same name in both (several) projects.
I believe, in such cases Visual Assist behavior must be based only on "compiler" point of view (where the scope is important). Currently, in such cases Visual Assist totally ignores the scope.
This many provide many incorrect, unneeded references, what may be annoying in large projects.
Why not to add an option which allows the user to restrict the listed results to the "visible" ones (from the "scope" point of view)?
It would be very useful in practice. |
| 5 L A T E S T R E P L I E S (Newest First) |
| accord |
Posted - Jun 17 2011 : 10:59:00 PM
We actually parse the important settings, including the ones you had mentioned. It is crucial for features like "Add Include" refactoring. |
| talamar |
Posted - Jun 17 2011 : 7:18:57 PM
I'm sorry, not "workspace", of course. :) Namespace.
Yes, current VAX behavior in such cases is quite optimal.
Otherwise, VAX would have to take additional detailed analysis of both the whole solution and each project settings (for instance, "VC++ Directories" and "Additional include directories"). And maybe, something else ... I didn't think about that.
Thanks, accord.
|
| accord |
Posted - Jun 16 2011 : 10:51:03 PM
What do you mean by workspace?
If you put them to a different solution, Visual Assist won't find each other.
If you put them to a different project, you can manually check what projects you want to modify. |
| talamar |
Posted - Jun 15 2011 : 8:09:59 PM
Thanks, accord.
So, the way to differentiate these two "foo"-s might be, for instance, placing each of them into separate workspace? |
| accord |
Posted - Jun 15 2011 : 6:35:40 PM
When you are doing a rename, Visual Assist presents the list in a treeview, where the root nodes group the results project by project. So just untick the project you don't want to rename.
I agree, the compiler works differently. Visual Assist looks only for the scope, in this case both foos are in the _tmain, in the global scope. But you are right, these are two unrelated files which don't includes each other so they are different compiler units. The thing is that Visual Assist pre-parses everything, every file when you load the project, and considers everything as a potential source that you might want to work with. That said, you can start typing symbol names from headers that are not even included and Visual Assist will help you. (Later, you can use the "Add Include" refactoring to add them.)
So if you have symbols with the same name, but in a different namespace or in a different class, etc. if will be differentiated. But two symbols in the global scope considered the same scope by VA. |
|
|
