I'm not so sure C/C++ solves the actual problem. Only sweeps it under a carpet so it's much less visible.
I'm not so sure C/C++ solves the actual problem. Only sweeps it under a carpet so it's much less visible.
You are right. But my conclusion is different.
If it is a stable and people have been there for a while then developers know that code as well as the rest. So, when something fails they know how to fix it.
Bringing generic libraries may create long callstacks of very generic code (usually templates) that is very difficult to debug while adding a lot of functionality that is never used.
Bringing a new library into the code base need to be a though decision.
Same here. And a lot of those homegrown functions, utilities and classes are actually already available, and better implemented, in the C++ Standard Library. Every C++ place I've worked had its own homegrown String class, and it was always, ALWAYS worse in all ways than std::string. Maddening. And you could never make a good business case to switch over to sanity. The homegrown functions had tendrils everywhere and many homegrown classes relied on each other, so your refactor would end up touching every file in the source tree. Nobody is going to approve that risky project. Once you start down the path of rolling your own standard library stuff, the cancer spreads through your whole codebase and becomes permanent.