Author |
Topic  |
|
beylevem
Tomato Guru
    
102 Posts |
Posted - Jun 03 2008 : 5:14:37 PM
|
Since I upgraded to 1638 (and now 1640), highlight references is not distinguishing between lhs and rhs contexts. All references are being marked in light cyan.
VA_X.dll file version 10.4.1640.0 built 2008.05.22 DevEnv.exe version 9.0.21022.8 msenv.dll version 9.0.21022.8 Font: Consolas 15(Pixels) Comctl32.dll version 6.10.6001.18000 Windows Vista 6.0 Build 6001 Service Pack 1 2 processors
Platform: Custom Stable Includes:
Other Includes:
Stable Source Directories:
|
|
beylevem
Tomato Guru
    
102 Posts |
Posted - Jun 04 2008 : 09:51:31 AM
|
I'm not so sure anymore that this is a new issue. It may have to do with the kind of variable.
This works:
int i, j; i = 1; j = i;
This has problems
class Array { operator [] .... };
Array i; int j; i[0] = 1; j = i[0];
If one highlights references for i, for the case i[0] = 1, the i is highlighted in LightCyan.
|
 |
|
feline
Whole Tomato Software
    
United Kingdom
19176 Posts |
Posted - Jun 04 2008 : 11:47:46 AM
|
For ease I have turned this into the following test code:
static void testGeneralCode()
{
int nLocalOne, nLocalTwo;
nLocalOne = 1;
nLocalTwo = nLocalOne;
std::vector<int> vecLocal;
int nLocalThree;
vecLocal[0] = 1;
nLocalThree = vecLocal[0];
}
I see the same problem when doing a Find References on vecLocal. I see the same behaviour in both VA 1626 and VA 1640.
In this specific case it is clear that vecLocal is being modified when it is assigned to. But in general, for "a function is being called on the LHS of equals" is the class instance the function is being called on actually being modified?
I don't think this is a new "problem". It is possible to argue that it is not even a problem at all, although I agree that it would probably be best if VA highlighted vecLocal as modified in this general situation 
case=4985 |
zen is the art of being at one with the two'ness |
 |
|
beylevem
Tomato Guru
    
102 Posts |
Posted - Jun 04 2008 : 2:02:39 PM
|
Feline, thank-you for your excellent follow-up on my skeleton code.
I would suggest that by definition, operator = is an assignment operator, and that quantities on the left hand side should be highlighted as being assigned to, provided that they resolve to an intrinsic type, or an object - i.e. as opposed to a function or function argument. |
 |
|
beylevem
Tomato Guru
    
102 Posts |
Posted - Jun 05 2008 : 11:15:20 AM
|
Having thought about this a little more, it would also be useful to distinguish between function declaration/definition, and function usage. E.g.
class Base { virtual void aFn() { default implementation; } }
class Derived : public Base { virtual void aFn(); void bFn(); }
void Derived::aFn() { specific implementation; }
void Derived::bFn() { aFn(); }
Derived anObj; void gblFn() { anObj.aFn(); }
The calls to aFn would be cyan and the declaration/definition rose.
|
 |
|
accord
Whole Tomato Software
    
United Kingdom
3287 Posts |
Posted - Jun 05 2008 : 5:07:00 PM
|
I am seeing the same effect here. Thank you for the clear description.
case=4442 |
 |
|
support
Whole Tomato Software
    
5566 Posts |
Posted - Jan 31 2010 : 1:39:16 PM
|
case=4442 is fixed in build 1810 |
Whole Tomato Software, Inc. |
 |
|
stefanr
New Member

Germany
7 Posts |
Posted - Jul 22 2015 : 10:30:27 PM
|
quote: Originally posted by support
case=4442 is fixed in build 1810
It seemed that the current build 2068 has the same color problem again.
E.g. If you search for all references of array a, the assignment is highlighted in LightCyan and not MistyRose.
int _tmain(int argc, _TCHAR* argv[]) { int a[2] = {}; a[0] = 1; int b = a[0];
return 0; }

|
 |
|
sean
Whole Tomato Software
    
USA
2817 Posts |
Posted - Feb 21 2018 : 5:50:15 PM
|
case=4985 is fixed in build 2258 |
 |
|
|
Topic  |
|