On one hand, I'd agree with you on that; I think we all know the urge to "modernize all the things!", whenever a language implements something new and shiny. And there's definitely much merit to resist that urge to some degree. However, it also is rarely really necessary to do this all in one go; one can also polish things up with strategies like the boyscout rule. And if there is no test for a piece of code - maybe leave it until you have corrected that.
Being conservative with new additions to your codebase seems a bit backward, though. Why not use the new, improved shiny language feature™ if you can?*
Of course, if you are prohibited by business requirements (e.g. missing modern compilers for a certain target platform) that's another story. Basically, it always comes down to practicality.
* A prime example would be the new way you can implement Singletons with C++11. Once you've used that, you realize how horrid pretty much all C++98-based attempts at this are.
Being conservative with new additions to your codebase seems a bit backward, though. Why not use the new, improved shiny language feature™ if you can?*
Of course, if you are prohibited by business requirements (e.g. missing modern compilers for a certain target platform) that's another story. Basically, it always comes down to practicality.
* A prime example would be the new way you can implement Singletons with C++11. Once you've used that, you realize how horrid pretty much all C++98-based attempts at this are.
Yes, I realize Singletons are often a bad idea.