2 ms·
I think we're working from different definitions of learning curves. I include in the learning curve understanding your memory ownership model, not introducing
by vvanders 5y ago
I think we're working from different definitions of learning curves. I include in the learning curve understanding your memory ownership model, not introducing use after free, heap corruption or other failure modes.
I would argue that if you don't understand the ownership of your data you don't really understand C++(or C) and you're still learning the language. That's usually the big shift I see when developers who have a background in higher level languages moving down to C++. I've seen plenty use after free and heap corruption happen in C++0x11 and onward codebases both staying completely within modern best practices and when code diverges since there's no guardrails(ex: std::string::c_str, std::unique_ptr::get and the like).
Once you include all the footguns that exist(yes, even in modern C++) and the legacy parts of existing codebases or code that diverges from modern C++ that's why I think it has a much higher learning curve to be producing code that is at the same quality as a passing compile from Rust in aggregate.
- moldavi 5y agoThat's reasonable; one's threshold of "safe enough" factors in. If one is just designing a game, or a command line tool for internal use, one needn't make it completely rock solid, and C++ has the better learning curve. If one includes the requirement to make it safer, Rust has the better learning curve. And then if someone actually values memory safety, they use a GC'd language and laugh at how many engineer-months and proofs it will take us to make code as safe as theirs. Sigh, such is life...