Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
 Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Feature Requests
 highlight references using & in new colour		  New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

Sneaky
New Member

United Kingdom
3 Posts
Posted - Jul 25 2007 :  07:04:35 AM  Show Profile  Reply with Quote
First up I love VAX and recommend it to all my colleagues.

Having just discovered that the Find references tool highlights assignments in a different colour to reading the value of a variable, I was wondering whether taking an address of a variable (i.e. &m_pFoo) should be highlighted in a different colour, especially as this can result in an assignment, for example pUnk->QueryInterface(&pDisp). Normally this would highlight pDisp in blue, even though a value is being assigned to it.

feline
Whole Tomato Software

United Kingdom
19020 Posts
Posted - Jul 25 2007 :  07:53:22 AM  Show Profile  Reply with Quote
This is an interesting idea.

My main concern is that taking the address of a variable is not a reliable indication of anything other than taking the address. I have often had to pass in a pointer simply because the function I was calling expects a pointer, even though it never updates the value of the variable.

Consider the function:

void updateInt(int &nFoo)
{
    nFoo = 1;
}


You would call this with the variable directly, but the function will update the variable.
zen is the art of being at one with the two'ness
Go to Top of Page

Sneaky
New Member

United Kingdom
3 Posts
Posted - Jul 25 2007 :  10:38:38 AM  Show Profile  Reply with Quote
Agreed. But perhaps that suggests that the find references tool should try to highlight in yet another colour if it finds a variable being passed by reference. I think my original point, that the use of the & operator could be highlighted in a third colour, remains valid though. The third colour would simply indicate that the value *may* change, not that it will change. In the example you cited of taking the address because the function expects a pointer, there's nothing to prevent the implementation of the function changing later to affect the value. I just think it would be helpful to highlight those instances differently to those where the value is just being used.
Edited by - Sneaky on Jul 25 2007 10:55:33 AM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
19020 Posts
Posted - Jul 25 2007 :  2:15:55 PM  Show Profile  Reply with Quote
This idea has a certain appeal, but consider the following functions:

void overloadOne(const std::string * const foo) { }
void overloadTwo(std::string *foo, int bar) { }

when calling the first function "foo" cannot be modified, but when calling the second function "foo" may be modified. To really make this idea work reliably VA would have to consider how the variable was being passed to the function.

Unfortunately this is not something we can currently do, since VA does not know which overload you are using when you call this function. This is why when you use alt-g on an overloaded function you are offered all of the overloads, and need to select the one you want to jump to.

We are looking into making VA understand overloaded functions, but this has not yet been done.
zen is the art of being at one with the two'ness
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000