| T O P I C R E V I E W |
| fmaddin |
Posted - Jun 09 2007 : 2:15:19 PM
I find myself not using the rename feature because I don't want to wait for it to search for the symbol. That is a shame. I realize that subsequent searches are faster, but I run into this enough to where I just use search/replace.
Many times I know the symbol only exists in the cpp file I'm working in and its header. It finds those quickly. But I have to wait for the search to complete across the whole code base before I can rename.
I'd like to be able to interrupt the search and rename only what it has found currently.
|
| 9 L A T E S T R E P L I E S (Newest First) |
| support |
Posted - Oct 29 2007 : 01:57:28 AM
case=7017 is implemented in Build 1614 |
| feline |
Posted - Jun 13 2007 : 07:11:30 AM
For alt-g, consider FSIW, VA has a "database" of the code, but this is where symbols are defined, rather than where they are used. After all, the full list of where symbols are used becomes the code its self.
An optimised rename, I see the appeal. Unfortunately I have also thought of an unpleasant edge case. Assume you are refactoring an existing class, and decide to use Encapsulate Field on a public member variable. Now make the member variable private. Now you want to rename / Find References on it...
At this point the optimised find says "no need to search to far", which means you can miss lots of references.
The second problem is what happens when the implementation of the class functions are split across 6 cpp files? Alt-o will only find one of these files, so VA will not "know" which files to scan for an optimised find.
Initially my reaction is a manual "stop" button on rename is the better answer, so the user can apply their personal judgement and experience to know when it is safe to do a quick find. |
| schoenherr |
Posted - Jun 13 2007 : 01:00:11 AM
maybe the effort should be spent to optimize the find reference feature rather in "breaking" an existing feature. reading the above posts it sounds like there are significant optimization possibilities.
e.g: searching references to a private member only in the class itself (and in classes/functions declared as friend)
also i can imagine a solution like this:
after a switch to a new source file VAX starts searching references for all symbols in the current file (starting with these symbols that are currently visible) in the background. theoretical this can be done for all symbols in the current workspace/solution, but i afraid that this would consume to much memory.
when i think of the alt-g feature and it's performance i would suspect that a mild form of such a "caching strategy" is already in use. |
| feline |
Posted - Jun 12 2007 : 4:05:45 PM
Many apologies, I did not mean to suggest you had.
Personally, as a programmer I like this idea. As the main support person for Visual Assist I am a little more concerned, since I don't really want to field complaints that "rename is broken" just because people are stopping it before it has finished finding all of the references *sigh*
Knowing you have to support a feature tends to show it in a different light  |
| sl@sh |
Posted - Jun 12 2007 : 12:03:34 PM
Hey, I didn't say the idea was bad - in fact I quite like it! Just wanted to point out you never should assume sth about your code unless you're the only one working on it. Sh*t happens ... even to the unsuspecting  |
| feline |
Posted - Jun 12 2007 : 09:05:10 AM
Private class members are fine, until you start adding friend classes. I have only needed to use friend classes on 2 or 3 occasions, but they were ideal when I really needed them.
Stopping the find early is certainly dangerous, but there are times when you can be 99.9% certain it is safe.
From experience there are easier ways of breaking the build, forgetting to add a newly created file is a well known method *sigh* |
| sl@sh |
Posted - Jun 12 2007 : 08:40:54 AM
Well, technically, even private members might be accessed through various different files - the class' method implementations don't need to be all in the same file after all
Yes, of course that would be very bad practice. Or would it? Looking at the project I am currently busy refactoring, I wonder how unrealistic such a thing would be: whenever I turn a struct into a class or move global functions into a class as a public method, I might not bother to immediately move the method implementation bodys as well - simply because I might not yet have a file for it. So, at least as a temporary state of my working copy there might indeed be newly privatised class members that are being accessed from seperate files!
Now consider someone else is doing the refactoring and - oops! - he forgot to move one of the method implementations to the appropriate implementation file before committing. You update your working copy to the newest version to have a look at the new class, and recognize one of the attributes' name really doesn't reflect it's purpose any more - it has changed over time, so a better name should be used, and VA provides neat functions to do the dirty work for you! You quickly change the name (locally only!) and even make another search to make sure VA didn't miss any occurences, or to fix comments. You only changed three occurrences, so you consider that not worth doing a complete recompile and just commit it to the repository. Then someone else wishes to make a change and gets the newest version. He does his change, tries to compile, and *bang*! There's an unknown symbol. Where does it come from? He doesn't know. Looking at the class the method that crashes belongs to he doesn't find any hint about that symbol either. If he's clever, he will check the most recent changes and eventually rediscover his problematic symbol in an older version of the code, but that will likely take some time...
Of course, these kind of situations would be the exception rather than the rule, I just wanted to point out that it might be dangerous to assume the code VA is working on is already in perfect shape |
| fmaddin |
Posted - Jun 11 2007 : 7:49:32 PM
Well I might own a cpp and h file (might not even be in use yet). Or the vars/methods might be private (oops I see you mentioned that). Or I might just have magic knowledge that it would be ok when I see it pick up all the files I know that depend on it.
I supposed if I'm wrong it might not compile. I certainly wouldn't blame VAX for that.
|
| feline |
Posted - Jun 11 2007 : 06:09:04 AM
Are you the only person working on your code? I am just curious, since the main concern is if someone else has come along and used the symbol without your knowledge.
I can see the appeal of this, and it should be fairly safe on private class member functions:
case=7017 |
