I work on a large software product which, being over 20 years old, has a number of constructs which have been superseded by language updates.One of these is a home-rolled smart pointer template class which acts similarly to - but is not quite indentical to - std::unique_ptr. The class has its destructor specialised for a number of types with specific destruction needs, and is referenced of the order of 150-200 times. It apparently works perfectly.Were the application to be written from scratch now, I'm reasonably certain that std::unique_ptr would be used instead. How aggressively should we pursue replacing the home-rolled class with std::unique_ptr; possibly including typedefs for the common specialisations with specific destructors?
How aggressively to change in-house smart pointer to unique_ptr?
c++;refactoring
This is a common problem for maintainers of old/legacy code, and there is no single perfect answer. Before making the decision to replace working code, I would propose trying to answer these three questions.Is it possible? Can you devise a method whereby existing instances of the 'old way' can be reliably replaced by the 'new way' such that each change is guaranteed to be made correctly, to be tested and to pass all tests, and that no new bugs will be introduced?Is there a benefit? Can you identify any aspect of the code that will be better after making this change? Will the code be faster/smaller/more maintainable as a result of the change? Will making the change uncover bugs you didn't know about? Is the benefit large enough?Is it enabling? Is this code under active development and there is some other planned set of changes that becomes possible/easier/safer as a result of first making this change (which would offset the risk of introducing bugs and the lack of a direct benefit)? Or is this a mature, stable code base that really needs to be protected against tampering by enthusiastic newcomers?This last is often the decider. If there are big changes ahead for this code then getting rid of obstacles like home-brew templates might well be justified, where otherwise it is usually best to let sleeping dogs lie.