How to handle step-by-step refactory of some heavily used libraries?

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 ex开发者_如何学Goample

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 A.h? 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\A.h and new\B\b.h?

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:

• The majority of the current applications will also be ported to use STL in time as they will all run on the new platform (still in doubt about RTX or InTime, but one of those).
• I do use a VCS, git, and pretty much everything that matters is covered by unit tests. Else this would be madness.
• There's no real team and I'm on my own (unfortunately I cannot count my collegue as a team member when it comes to things like this, though being almost twice my age his programming level is less then half of mine, and I'm not even that skilled.

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.