| T O P I C R E V I E W |
| AjayV |
Posted - Mar 06 2012 : 2:58:30 PM
Let's have a class in header file:
class CTest
{
};
And add prototype of new function:
void foo(); // Header And, now using refactoring feature, do 'Create Implementation'. Alright, it will place implementation in CPP file.
But... if the CPP file is having state, at the end of file, like:
#if _SOME_MACRO_DEFINED_
// Some previously-defined/not-needed implemented methods
void CTest::other()
{
}
bool CTest::IsOther()
{
return false;
}
#endif
// END OF FILEIn this case, VA will put implementation of
new function just before '#endif', and it may cause linker error. IMO, it should place implementation of new method around end of file.
I understand VA tries to intelligently place method implementation, after the last implemented method of same class. |
| 5 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Mar 13 2012 : 4:42:35 PM
For comments after functions, how well "attached" is the comment to the function? How can VA reliably tell that the comment applies to the function above, and not to the function below?
Comments above functions sometimes contain blank lines, so deciding when a function is attached to a comment requires some guess work, so we need to be careful making changes here, not to break existing comment support. |
| AjayV |
Posted - Mar 12 2012 : 1:49:32 PM
All fine! 
But I don't completely agree with "workaround" comment. Working in a team, we often write new code, or change existing. When we add new function, we would put comment at both ends of it - mentioning the developer name and date/time. Create Implementation would move the last end-comment to the end of new implementation, and so on.
|
| accord |
Posted - Mar 12 2012 : 02:59:59 AM
I get it. But let me give you an example:
header:
#ifdef _SOMETHING
class someclass
{
void method();
void method2();
};
#endif
cpp:
#ifdef _SOMETHING
void someclass::method()
{
}
#endif
If you do a Create Implementation on method2(), so you will get the correct result:
header:
#ifdef _SOMETHING
class someclass
{
void method();
void method2();
};
#endif
cpp:
#ifdef _SOMETHING
void someclass::method()
{
}
void someclass::method2()
{
}
#endif
My point is that sometimes the current method works better, sometimes end of file version would. But creating the method always EOF won't help in every case, but it would cause random methods in the file without intelligent grouping by classes.
Regarding your example: VA handles comments and functions together when they are before the method, like:
//somecomment
void someclass::somemethod()
{
}
You can write comments before the method and not after it as a "workaround". |
| AjayV |
Posted - Mar 09 2012 : 3:17:40 PM
Alright, take another example.
void CWindowCore::OnPrint()
{
}
// This is comment for OnPrint. END OF FILE
Add new function in header:
void DontPrint();
Now, when I do 'Create Implementation', it will mess it up like this:
void CWindowCore::OnPrint()
{
}
void CWindowCore::DontPrint()
{
}
// This is comment for OnPrint.
Instead of doing it like:
void CWindowCore::OnPrint()
{
}
// This is comment for OnPrint.
void CWindowCore::DontPrint()
{
}
Get what I am saying? |
| accord |
Posted - Mar 07 2012 : 7:38:10 PM
It seems trivial what to do in your example, but consider the opposite case, where you need (compile) the functions that are inside the #if ... #endif block and you don't need (don't compile) those outside. In that case VA would have done the right thing. And these are very simple cases, users do much more "ugly", utterly complicated things with macros. I don't see a way to figure out what to do, algorithmically. VA cannot always place the result to the right place when macros are involved.
But fortunately VA keeps the selection around your new implementation so it is super easy to just cut and paste the implementation to the right place  |
|
|
