Refactoring a codebase from manual memory management to RAII

Question

Edit: @Ben Cottrell's comment said this was similar to a question about spaghetti code. While both questions involve large codebases, mine addresses a specific technical pattern: manual memory management vs RAII, with concrete examples of the current structure. The other question asks for general legacy code strategies, and its answers (VCS, testing) don't address my specific object lifecycle refactoring challenge.

I've inherited a large codebase (around 200k lines) and I'm trying to understand the best way to modernize its object lifecycle management. The code is actually well-organized in many ways:

The project is split into many classes (100+) with good separation of concerns. However, it has an unusual pattern for object lifecycle management that relies heavily on manual memory management with raw pointers.

The current pattern looks like this:

Each class T follows a specific structure:

• Headers (T.h) contain class declarations with basic constructors/destructors and accessors
• Implementation files (T.cpp) have mostly empty constructors/destructors
• Separate files (T_func.h/cpp) contain the actual initialization logic in standalone functions

The initialization happens through functions like T_func::build_T(T&, ...) rather than in constructors. Similarly, cleanup occurs through T_func::clear(T*) functions instead of destructors.

There are some interesting constraints:

• Some destructors are protected, forcing you to use the clear(t) functions (sometimes those just delete t, triggering the empty constructor, so this is equivalent to delete t but prevents stack allocation)
• Initialization can be multi-stage, where build_T_1() must be called before build_T_2()
• These initialization stages often work with hierarchical object structures
• The stages can span multiple modules

The getters and setters are basically just direct access to member variables.

I'd like to refactor this to use modern C++ patterns - specifically RAII where objects manage their own lifecycle and can be stack-allocated. Any suggestions on the best approach?

• freakish: The main question is: why is the structure as it is? Is it possible that build and/or clear functions may fail and you have to react to it? If so, then you cannot use RAII. Otherwise it is just a long, tedious job of rewriting everything. Also, my suggestion is: always prefer composition over inheritance.
• Ben Cottrell: This question is similar to: I've inherited 200K lines of spaghetti code -- what now?. If you believe it’s different, please edit the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem.
• Arno: @BenCottrell Thanks - I've edited to clarify. The linked question addresses general legacy code practices, while this focuses on a specific memory management pattern. The codebase is actually well-structured, just using dated C++98 patterns that complicate development.
• amon: I don't think there's a lot of good guidance that can be given here. Bit by bit, update the classes to conform with "Rule Of 0/3/5". Where owning pointers are necessary, migrate to smart pointers (unique/shared). You can likely introduce a lot of unique-ptrs right now with clear() as a custom deleter. The hardest part will be multi-stage initialization. Sometimes this has to be kept, sometimes a Builder or Typestate can help make this more maintainable.
• kiner_shah: Just remember, always measure when refactoring. If the changes you did worsens the performance, then it may not be worth it.

Answer 1

It may sound trivial, but the approach which will probably serve you most is quite generic:

1. Identify a class you want to refactor next.

2. Make sure you have enough regression tests in place for this class.

3. Rewrite the memory management for that class

4. Run the tests, fix the bugs.

5. In case you are satisfied, go to step 1.

Of course, it may happen that your slice of work was too large, and you don't get the code base stable within a reasonable amount of time (for me, I avoid refactoring cycles longer than one day, but YMMV). If you run into such a case, undo your latest changes and try to find a smaller slice.

I would also consider to focus the refactoring on parts of the code base you expect to have to touch for new business features next, or where you know there is a hidden bug. Don't mess around with working code when you don't have no other reason to look into than "the memory management is old-fashioned".