| T O P I C R E V I E W |
| Mordachai |
Posted - Sep 30 2014 : 10:13:25 AM
Long standing issue (I know we're an unusual customer in this respect...)
We have a humongous class "CMacroInterpreter", with hundreds of methods. It would be obscene to try to put them all into a single .cpp (it was originally divided up because the compiler would fail to compile the darn thing - out of memory or whatever internal buffers caused it to balk). So they're split up into various .cpp files.
When I use "Refactor - Create Method" - VA wants to always move it into "MacroInterpreter.cpp", instead of whatever .cpp I'm currently editing (it stands to reason that most of the time when I'm refactoring a method in a given .cpp, the new method should also be in that same .cpp since it is intimately related to the other method(s) in that .cpp).
Here's something concrete to get a better feel:
MacroInterpreter.h - class header
MacroInterpreter.cpp - class overhead stuff - like ctors, dtors, etc.
Macro Parse Strings.cpp - members related to string-parsing for the interpreter
Macro File Commands.cpp - members relating to interpreting / performing file related commands in our macro language
Macro Error.cpp - members relating to macro language error handling (stack unwinding, reporting, etc.)
... (there are 157 files that comprise CMacroInterpreter, including the header).
So, when I'm editing something in Macro Parse Strings.cpp, and I need to factor out some code into its own method, the two most likely places are: this .cpp file, the header (in that order).
----
On a related note, we have classes that are arranged thus:
Class.h
Class.inl
Class.cpp
It would be nice to have the refactoring mechanics allow me to choose where to put the inline code. Perhaps when the code is being refactored to the "header" - if there is an .inl file, it should be redirected there by default (since the purpose of having a .h and .inl is - in my experience - primarily to keep a clean .h with details squirreled away in the .inl - although it is also to allow the .inl to be either #included in the header or the .cpp depending on build options, which is sometimes useful for debugging purposes).
----
If there is anything else I can support this idea or to make it more clear, please let me know. I hugely appreciate this product and the superb support you all have given me in the past. :D |
| 7 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Oct 04 2014 : 7:57:03 PM
Now I see what you are after, it is a very reasonable and interesting piece of icing on the cake, and yes, we all do enjoy icing on the cake  |
| Mordachai |
Posted - Oct 02 2014 : 9:24:11 PM
Yeah, this is an icing feature. Cutting it and pasting it where I want is trivial.
It's more that it causes an automatic check-out from our source control, and then the need to unwind that check out. Again, icing on the cake, but heh, who doesn't like icing?!  |
| feline |
Posted - Oct 02 2014 : 7:01:44 PM
I think it will, I included a couple of examples of the idea in the feature request, so now we have to wait and see what they make of it.
For now, when you use Extract Method the new function should be selected in the cpp file, so you can cut the new function, use Ctrl-Tab once or twice to get back to the cpp file you started in, and then you can paste the function body where you want it to be. Hopefully a helpful thought to help for now. |
| Mordachai |
Posted - Oct 02 2014 : 08:22:38 AM
Thanks. I hope that makes sense to your devs. |
| feline |
Posted - Oct 01 2014 : 8:45:32 PM
Presenting you with a list of 156 files is the very thing that scared me off as well! I see what you are getting at now, I had not thought of that, but returning to the current cpp file makes perfect sense in this situation, it also makes sense if you are working in a .inl file. So I have put a feature request in for this to see what our developers make of it:
case=85362 |
| Mordachai |
Posted - Oct 01 2014 : 08:31:27 AM
feline - if VA could just default to putting the new implementation in the same file being edited, that would work (after all, if you're editing a method, and you refactor-extract a method, that method will be for the same class. So you're already in the one cpp for that class for everyone else, but you're in the right file for someone like me where we have more than one .cpp per header).
I'm not wanting a fly-out with 156 possible .cpp files to choose from! 
Rather, just that "Refactor->Extract Method..." should default to "implementation file == current .cpp" (if I'm not in a .cpp, then the normal rules are fine. Same with the choice of NOT Extract to source - that would use the current rules of placing it in the header (or .inl if you implement that option!)
So, it seems like this idea would dove-tail with what your other customers are already expecting, would need no new understanding from VA (it doesn't need to know about the 156 .cpp file relationships), just an optional setting to use the current .cpp file when "Extract as Free Function" or "Extract to Source" are chosen.  |
| feline |
Posted - Sep 30 2014 : 5:40:31 PM
Your first situation, splitting the code across 157 files, I don't fancy even thinking about that. To start with, VA has no way of realising these files are related, and trying to tell VA that they are related is just a mess, unless you have an actual simple and reliable pattern for listing the full set of files. "Macro*" would work, but seems rather loose.
Are you aware that VA Outline makes it quick and easy to select functions you want to cut and paste, to help with moving them to another file?
For the .inl files, having Create Implementation automatically place the function into the .inl for "inline" functions makes sense, I have put in a feature request for this:
case=85337 |
|
|
