|T O P I C R E V I E W
||Posted - Oct 29 2007 : 12:53:32 PM
I think I found a bug in find references. Consider this example:
typedef SomeType blabla;
Then find references on the typdef 'blabla' will give 2 results:
- #include <blabla>
- typedef SomeType blabla;
where the first one is clearly wrong.
The strange thing is that if you do a rename on the same symbol, then a '?' is placed next to the include.
|9 L A T E S T R E P L I E S (Newest First)
||Posted - Sep 13 2012 : 2:04:11 PM
case=1463 is implemented in build 1916
||Posted - Apr 10 2008 : 01:13:55 AM
case=9592 is fixed in build 1632
||Posted - Oct 31 2007 : 11:30:37 AM
If you are using VA 1614 and run Rename it should *never* rename any #include line by default. It may find some #include lines, but they are never selected by default. You can choose to tell VA to rename them, and it will then do so, but only if you tell it to do so.
In this case the "easy" solution would be to leave all of the items in the Rename dialog checked, including #include lines, since this is less work than finding and unticking the #include lines.
Renaming files comes up periodically, as a feature request:
but currently we have no plans to try and do this. Problems with source control systems are one reason why we are currently avoiding this feature.
||Posted - Oct 31 2007 : 10:17:23 AM
But how if i don't want to rename file name then i would uncheck n checkboxes or i'll check if i wanted to rename. Or if filename is totaly different from renamed class, then how should i refactor the include references.
Filename is a different caoncept in C++ that a filename can be different from class name, one file can include many classes and of course class and file may both have the same name.
So adding a "Rename include references" is still a better option.At least until a better one is explained.
And this still means my statement is not totaly wrong
||Posted - Oct 31 2007 : 09:18:46 AM
If you would look closer, then you would see that VAX only matches the include statement in 'find references'. During a rename it is matched as well, but with a '?', and so the include statements are not renamed by default, but should be selected manually.
Saying that the guys at the tomato choose the easy way is a bit of a harsh statement and at least for this case totally wrong.
||Posted - Oct 31 2007 : 09:01:08 AM
I think including a feature like "Rename header references" is more sensible.It's also common that a file can contain multiple classes so renaming include file with class rename can make an inconsistent situation.
Changing include references on class rename is dangerous and not quite right.So if VA is "written by the developers for developers" then these "developers" should think something like that.
I think "developers" have chosen the easy way to implement such a feature...
||Posted - Oct 29 2007 : 3:24:30 PM
A lot of our users name #include files after the class they contain. I know since people keep asking for VA to rename the header file and all #include statements when they rename the class.
So from this point of view, what happens here does make a degree of sense.
Still I agree that the #include lines are not always related, so this is a good use of the question mark icon in Find References Results
||Posted - Oct 29 2007 : 1:50:13 PM
Probably you mean INcorrect behaviour?
I can see why it would be useful, but it seems to be rather coincidental if it matches. It depends a bit on how you work: I put the namespace name in my filename, so that makes that this 'feature' will always be wrong if it matches an include.
In my opinion, the best thing to do would be to put a question mark in the find references result, just like in the rename result.
||Posted - Oct 29 2007 : 1:41:30 PM
I am wondering if you can make a good argument for this being the correct behaviour.
Clearly for the typedef it is not what you expect, but if you are doing a Find References on one of your class names, and the header file uses the same name as the class, then this might actually be useful.
At one point VA was actually renaming the #include lines, which was definitely wrong, and has been fixed in VA 1614.