4 ms·
> standards committee or bjarnes, what they're going to tell you is to rewrite it The same will be true for Rust in 50 years (assuming Rust doesn't die any tim
by staunton 3y ago
> standards committee or bjarnes, what they're going to tell you is to rewrite it
The same will be true for Rust in 50 years (assuming Rust doesn't die any time soon). If they didn't think it was worth modernizing, they'd just leave C++ alone (which I think they should, but that's another matter).
For old C++, you run valgrind and a linter on it and if nothing comes up it's also "probably fine". At least it's hard for me to think of a situation where the most productive/profitable-for-buisness thing a developer can be doing is modernizing their old C++.
- AlotOfReading 3y agoWould you bet your life/money/application security on valgrind and a linter being sufficient to catch all of those issues, knowing that a single mistake invalidates every guarantee the standard gives you? That's the situation we're in with C++. When you're building old code, the compiler can't check that it upholds the standard to the degree that it can for modern C++. That's why the advice is to update the code, because the tooling can't save you otherwise. Rust by contrast guarantees that you either have a compiler/runtime bug or the issue is more narrowly localized than "potentially every single line of code". Sure, I'd like better, but it's an improvement.
- staunton 3y ago> Would you bet your life Definitely not. But it's rare that so much is at stake. I would not bet my life on the borrow checker either, there's a lot of things that can go wrong in a program. Money is of course a question of how much. Application security is just "the above". The "undefined behavior can explode your PC, travel back in time and become your father" problem is not to be underestimated. However, in cases where old code works well for years but really has some lurking bad UB, one can disable some optimizations and be conservative with compiler choice. A lot of people dislike the trend towards compilers being ever more punishing of UB and I can see their point, while it's of course hard to argue for (let alone find) a balance between performance and some robustness to ubiquitous and almost inevitable code issues. Rust's giarantees are nice and I sure would prefer working on a modern Rust project than any C++ project, as well as a modern C++ project compared to C99-with-classes. Modernizing existing code is a different matter. I've seen very few attempts at modernizing a big and old C++ codebase, no attempts where it clearly paid off and one attempt where it went wrong...
- shrimp_emoji 3y ago> If they didn't think it was worth modernizing, they'd just leave C++ alone (which I think they should, but that's another matter). What about C? That's being modernized too, sometimes with novelties from C++ modernization, like `nullptr`! :p https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3042.htm https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3042.htm
- staunton 3y agoThe amount of new syntax and programming concepts being constantly crammed into C is much smaller. If I had to quantity it, I'd estimate that C++ is by now roughly 3.5 programming languages in one while C is maybe 1.5... The more stuff you have the more problematic (adding foot guns and making it hard to learn a language) it is to add more stuff because it all interacts. And a lot of C++ features interact in bad ways...