| Author |
 Topic  |
|
|
Mordachai
Tomato Guru
USA
224 Posts |
 Posted - Aug 08 2016 : 10:28:00 AM
|
I love the "introduce variable" feature...
but (sorry)
... I want to set the data types NOT TO BE the LPCTSTR style abominations.
e.g.
_T("foo") -> refactor -> const TCHAR kMyString[] = _T("foo");
NOT
LPCTSTR kMyString = _T("foo");
I can live with
const TCHAR * kMyString = _T("foo");
but the LPCTSTR (and its ilk) rub me the wrong way (generally speaking, pointers should never be hidden inside of a typedef in C++ - that accommodation was for C back in the '90s, and was obsolete by C++ '03.
so... how I can configure how refactoring chooses its data types? |
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Aug 08 2016 : 7:31:45 PM
|
You cannot configure it right now, but this is a very sensible request so I have put in a feature request:
case=99250
At least changing it to const TCHAR * would be sensible. |
 |
|
|
Mordachai
Tomato Guru
USA
224 Posts |
Posted - Aug 09 2016 : 12:00:32 PM
|
Thanks. Having a few such options would be nice. The other LPxxxx struct-pointers that Windows.h and its ilk use are also verboten in my code (e.g. LPRECT). Just a pointer to the underlying type would be a fine option for the refactoring tool, IMO.
Maybe there's an opportunity for a more generalized substitution table - just a simple "if you're reaching for X, use Y instead" (LPCTSTR -> const TCHAR *, LPRECT -> RECT *, etc.)
Such a "substitution table" could be a simple text file, and would be trivial to maintain, and should be easy to parse into a map for good performance, and would be generic enough to handle more than this one issue I'm presenting.
Anyway, just a thought from an "outside" perspective (I can't see under the hood to know if this is a good or bad suggestion). ;) |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Aug 09 2016 : 8:42:08 PM
|
| Thanks, I have added a comment to the case with your idea of a replacement table. |
|
|
| |
Topic |
|
How to configure refactor?
