Any way to get references appropriate to the scope of the variable?

[NightStorm]

VSE 11.0.1

In C, I have a routine like so:
    int  SomeRoutine( int param1, char * param2 )
    {
         int   local1;
             o
             o
         return something;

    }

Parameters "param1" and "param2" as well as local variable "local1" all are commonly used throughout the project as names however their scopes are always well limited.  If I click on any of these then Cntrl-/ to find where they are referenced, sometimes I get every reference in the entire file that uses a variable by that name.  What is worst is that sometimes I get every reference in every file in the entire project.

Is there any way to have SE only show references consistent with that variables scope?

TIA,

           - Bruce

[srouleau]

I don't know if it's possible, but I'd like to do a "Me too!" on something similar.

if I'm on a symbol and I press Ctrl-. I'd like it to be restricted as much as possible.  For instance:

something.lenght();

Now there might be tons of 'length()' in the project, but it'd be nice if it was limited to the class hiearchy for 'something'...

[magpie]

Yeah, me too. Isn't this the point of "Context Tagging" ?

[Dennis]

In fact, Context Tagging does restrict symbol searches and references to the appropriate scopes, whenever possible.

However.

There is a problem with nearly all C/C++ code:  preprocessing.  Seemingly innocuous little macros like "MY_CDECL" or "MY_PACKED_STRUCT" or "MY_EXTERN_C" or "MY_NAMESPACE_BEGIN(ns)", "MY_NAMESPACE_END", or "MY_USING_NAMESPACE(ns)" turn what could be beautiful C++ into gibberish as far as our parser is concerned.  The solution, as always, go to Tools > Options > Tagging Options..., click on "C Preprocessing..." and define your macros so that the parser can deal with them.

There is also a problem with some people's C/C++ projects:  They are missing the header files, or third party libraries in their workspace, so SlickEdit is left with incomplete symbol information.

So, right there are two solutions to making Context Tagging and References work more effectively for you, but let's look more closely at your example and the potential failure points:

Code: [Select]

   something.length();

So, you want to jump from "length()" to it's definition?  To do so, SlickEdit has to find:

1) the declaration of "something"

This could be a failure point, if there is preprocessing around the declaration that turns it to gibberish.  This is also a failure point if you are coding in a silly scripting language where you do not declare variables -- if so, the choice of programming language has crippled your editor.

2) the declared type of "something" -- let's say it is "SomeThing_t"

Again, prepreprocessing could cause this to be a failure point.  Or, if you are using a language where you declare variables but they are all essentially typeless containers (like JavaScript) -- again, the choice of language cripples your tools.

3) the declaration of the "SomeThing_t"

Again, preprocessing could be a problem.  Also, if SomeThing_t is declared in a header file that is not in your workspace, this will be a failure point.

4) the declaration of "length()" within Something_t, and it's definition.

Again, preprocessing could break this.  Also, if length() is inherited from a superclass, SlickEdit has to follow the inheritance chain to find it.

---
PS.  You may ask why doesn't SlickEdit just do full preprocessing like the compiler does in order to solve some of these parsing problems?  The answer is performance and simplicity.  To do full preprocessing you need to know the exact header file search path, as well as command line #defines, and built-in #defines.  Right now, context tagging works really fast with minimal setup for most code.  Based on that, the current solution is a very reasonable compromise.