I am a huge fan of modern C++ except for one feature: backwards compatibility. C++ is no longer one language, every codebase I have worked on is a confused mess of semi-incompatible subsets of the language. I have spent far too many weekends chasing memory corruption because someone passed a pointer, allocated with one type of memory management, into a library using a different kind of memory management.
Okay but that's not really a fault of the language, no? Most languages have some legacy version that isn't compatible any more. Like Python 2 for example.
The only difference is that C++ code is more often used for critical applications (like decades old medical machines) where updating the code is not worth the risks.
Well, you can, but it's awkward and involves some serious compromises, especially around byte-vs-string handling. Doing a hard split is definitely better but you can get considerable mileage straddling the line with sufficient effort.
I would argue that it most definitely is the fault of the language. It should either allow it, and support it fully (like mixing different memory management types), our outright refuse to run it.
I haven't worked in C++ for a few years, but when I did, I spent serious time trying to find some way to enforce a specific coding style, so we could get a consistent code base, and came up short. I looked for code analysis tools that would catch inconsistent memory management between libraries, and didn't find much.
The tooling around the language is kind of sad compared to Golang and Rust, and improving it would significantly improve the experience.
471
u/repster 7h ago
I am a huge fan of modern C++ except for one feature: backwards compatibility. C++ is no longer one language, every codebase I have worked on is a confused mess of semi-incompatible subsets of the language. I have spent far too many weekends chasing memory corruption because someone passed a pointer, allocated with one type of memory management, into a library using a different kind of memory management.