I have a couple of libraries that were targetting multiple platforms, of which some realtime ones that did/do not have decent STL support, let alone tr1 or C++11. This means everything uses the library's own string/array/list/younameit classes. Now these platforms are getting abandoned in favour of 'pure' C++11 and STL (which I am very very glad for: the latest lib I did is the first one with the new standard and development time has shortened a lot, while code quality went up).
Now I want new projects to not depend on the custom string/array/... classes, and I'm planning to go for a step-by-step refactory: whenever I need some class, create a duplicate (well not a complete duplicate; still that hurts, but is there another option?) that uses STL instead. In the beginning that might mean a whole tree of classes might need changing at once. At the same time the original code should keep working for the next 4 years or so.
Practically the main question I'm facing now is: where do I put these new classes? For example
A\A.h depends on B\B.h and string.h
should become
a new A.h depending on a new B.h and <string>
Do I make a new class NewA and put in in Ah? Or make a class A in a new namespace and store it in A\\newA.h
? Or do I make a whole new subdirectory structure like new\\A\\Ah
and new\\B\\bh
?
I know there are already a couple of similar questions, with great answers, but I'd like some more practical advice, not "read Working Effectively with Legacy Code". Though that is, with reason, a good answer, I'm more interested in what you practically did in a similar situation?
edit some clarification:
Don't duplicate classes. Let your old project run, and fork it somewhere. Of course, use unit testing and source control.
Then, I'd go for a depth-first approach, a bit at a time. Change one class at a time to adapt it to the new coding standards, and solve all compiler errors that result. This means in particular that for the class you are interested in, you first get rid of the old string.h
, you change the interface and implementation (string/vector classes aren't that different from one another), and you build the project. Let compiler errors tell you where to go next.
Depending on the size of the project, you can begin with the least or most used class. Remove unused string/vector classes only after all the other classes have been converted.
This is likely to be a quite easy (albeit time consuming) operation (hence different from refactoring) and this can probably be handled quite well by multiple developers at a time, if you use a good version control system with good merge support and unit testing. Do use unit testing and version control. Really do.
Of course, you won't adapt your entire code to STL and C++0x, and you should strive first for the custom string/container classes, and add smart pointers where they belong. Your mid-term goal should be to remove every occurrence of delete
in your whole code base.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.