| T O P I C R E V I E W |
| Mordachai |
Posted - May 08 2012 : 1:04:13 PM
Our project has a very large class - CMacroInterpreter, which has hundreds of methods. These methods are implemented in many .cpp files, not just one.
It has been frustrating for years in VAX that when I want to change a method declaration or do anything with a method (including create a new new method or refactor header->cpp), that VAX fails to grok this idea that the many .cpp files that all define members of CMacroInterpreter are in fact equally (or cumulatively) the .cpp that corresponds to CMacroInterpreter.h.
So, some examples:
in 'Macro Dialog.cpp', right-click on:
void CMacroInterpreter::RunSomeDialog(int ID)
I cannot access anything in the refactoring menu that relates to knowing about the declaration (even though VAX does know about this method and its .h file and so on at some level because it is parsing everything properly).
So no (0):
Change Signature
Move Implementation to Source File
Doesn't work well (1):
Extract Method
Create from Usage
Broken (2):
Create Implementation
(0) disabled
(1) always puts the code-body in CMacroInterpreter.cpp - despite extracting the method in some other .cpp file, such as Macro Dialog.cpp.
(2) enabled when it should not be, because the implementation already exists
--
This has been very frustrating for many years, and would a truly lovely bug-fix/feature addition if this could be addressed.
Simply defaulting to extracting a method or creating from usage to the same .cpp or .inl file I'm already in would be more than adequate. Enabling/disabling the various refactoring methods correctly would be huge.
Thanks for looking into this, and for a great product overall!  |
| 8 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Sep 13 2024 : 12:16:32 PM
I have added a second test case, so this time I have the files:
test_pure_split_alt_o.h
test_pure_split_alt_o_part1.cpp
test_pure_split_alt_o_part2.cpp
test_pure_split_alt_o_part3.cpp
and only these files. All of these files are in the same directory. Pressing Alt-O in any of these 4 files lists the other 3 files. So Alt-O at least should be working for you. I have double checked, and this test case works correctly with VA 2511.
For VA moving an implementation from the header file, VA is looking for the cpp file that exactly matches the header file, so I have put a note on the case about this, explaining the situation you are using.
Unfortunately no progress on this yet, or an estimate, since this is something of an edge case. |
| Pago |
Posted - Sep 12 2024 : 05:17:39 AM
test_split_alt_o.h
test_split_alt_o.cpp
test_split_alt_o_part1.cpp
test_split_alt_o_part2.cpp
test_split_alt_o_part3.cpp
this is our structure.
then it wont work.
VA 2511
VS 2022 version 17.10.6
PS:
If i make a test_splitt_alt_o.cpp:
- extract method in part1.cpp works, but makes the new part into test_split_alt_o.cpp
- extract method in header also into test_split_alt_o.cpp
- Alt+O still not working |
| feline |
Posted - Sep 11 2024 : 09:59:29 AM
Which version of VA are you using?
Using VS2022 and VA 2530, I have tried the following simple test case. I have the files:
test_split_alt_o.h
test_split_alt_o.cpp
test_split_alt_o_part1.cpp
test_split_alt_o_part2.cpp
test_split_alt_o_part3.cpp
Alt-O knows that these all belong together, and offers to let me jump between them.
Sitting in "test_split_alt_o_part1.cpp" if I trigger Extract Method, it works normally. The new class method is placed, inline, into the header file "test_split_alt_o.h" where the class is declared.
If I trigger Extract Method from the header file, VA is targeting the file "test_split_alt_o.cpp"
Am I testing this correctly? |
| Pago |
Posted - Sep 11 2024 : 05:52:16 AM
Is this feature still considered?
We too have some classes that are big, with many files.
All with same headername+suffix.cxx
For example Extract Method fails in header and wants to create file. |
| accord |
Posted - May 10 2012 : 7:09:21 PM
About void CMacroInterpreter::RunSomeDialog(int ID) in the cpp file:
- Move Implementation to Source File is not available because by source file we mean cpp, and the function is already in a cpp file.
- Change Signature: yesterday I saw problem for a short amount of time, but I wasn't able to reproduce it anymore, maybe it was only a timing problem since I added new files and methods to a few files. Does this method have overloads?
Extract Method and Create from Usage: you mean it may use the wrong file, right? It was addressed above, and covered the enhancement request that I had put in.
Create Implementation (1) is also about using the wrong file, right? (2) unfortunately VA is not able to handle overloads, so cannot verify for sure if a method has already been implemented. Is this something that bothers you or just mentioned?
(0) disabled: this is odd. It should not be disabled. Do you see a pattern, which type of methods cause this? Is it possible that this is a timing issue? VA needs up to a few seconds (depending on the file size) to reparse a file after it has been modified. |
| accord |
Posted - May 09 2012 : 3:33:55 PM
Regarding Create/Move Implementation to "fly-out": I have put in an improvement request for this, to see what the developers make of it:
case=66620
I'm not sure whether this is viable, or would be too slow to check all cpp files. Goto can jump, so there is a chance, but we are talking about hundreds of methods here, while goto needs to work with only one at a time.
I wasn't able to reproduce your other problems consistently so will investigate further. |
| accord |
Posted - May 08 2012 : 9:07:18 PM
Good ideas. Most use one cpp per header file, so these problems don't occur.
I will address your ideas separately since it may take a little more time.
First, about the refactorings that were executed from the source files: they should choose the same source file when deciding where to put the result. I have put in an enhancement request for this:
case=66607 |
| Mordachai |
Posted - May 08 2012 : 1:06:56 PM
As a follow-up idea:
Allow "Move Implementation to >" fly-out, that lists the corresponding .cpp files, so that it's trivial to move a method-body from one .cpp to another (within the set of files that comprise that class's definition). |
|
|
