3 ms·

Wouldn’t you say that “understanding what your doing” applies a little more to C/C++ than many other languages/tools/etc? Both Microsoft[0] and Google[1] have e

by garren 4y ago

Wouldn’t you say that “understanding what your doing” applies a little more to C/C++ than many other languages/tools/etc? Both Microsoft[0] and Google[1] have established that ~70% of the defects they encounter in their flagship products and systems are memory-related, and generally attributed to the “dangers” of the underlying language: C++ It seems significant that, given that the individuals working on these projects are professionals, experts by some definition, they too are encountering issues related to the sharp edges of these languages. Issues that have wide ranging implications. In light of that, doesn’t saying that “understanding what you’re doing” is all it takes to productively and safely use a language like C/C++ seem simplistic? Even the experts are getting it wrong. I took a couple C++ classes in college. I’ve worked on both desktop and backend C++ systems in both C++98 and ‘11. It can be a difficult language, it has more than its share of footguns, it definitely helped me appreciate other languages that don’t have similar issues. [0] https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... [1] https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...

nyanpasu64 4y ago
I prefer Rust's approach to spatial memory safety over C++; it doesn't get in your way and it's good at preventing out-of-bounds access at a low performance cost. I also like Rust's approach to threading over C++; in a world where data races are undefined behavior and the typical C++ threaded program (both from before and after C++11's memory model) is an entangled UB-filled mess impossible to refactor, Rust's Send/Sync and &/&mut is needed discipline to organize programs. I'm unconvinced by Rust's insistence on temporal memory safety (the compiler follows fixed rules, it takes unsafe code to teach it about things like scoped threads) and "aliased xor mutable" (which rules out even many correct C++/Java architectures and requires either dangerously tricky unsafe code or needless rewrites in safe code, and optimizes for local reasoning at the cost of flexibility and expressiveness, which is sometimes a bad tradeoff, and SB is a needlessly strict nightmare with no equivalent to unique_ptr supplying RAII deallocation without noalias semantics). Though it is wise to be cautious in C++ around objects with self-pointers (unsafe to move) or aliasing member pointers (tricky lifetime constraints).

by garren 4y ago

nyanpasu64 4y ago

I prefer Rust's approach to spatial memory safety over C++; it doesn't get in your way and it's good at preventing out-of-bounds access at a low performance cost. I also like Rust's approach to threading over C++; in a world where data races are undefined behavior and the typical C++ threaded program (both from before and after C++11's memory model) is an entangled UB-filled mess impossible to refactor, Rust's Send/Sync and &/&mut is needed discipline to organize programs. I'm unconvinced by Rust's insistence on temporal memory safety (the compiler follows fixed rules, it takes unsafe code to teach it about things like scoped threads) and "aliased xor mutable" (which rules out even many correct C++/Java architectures and requires either dangerously tricky unsafe code or needless rewrites in safe code, and optimizes for local reasoning at the cost of flexibility and expressiveness, which is sometimes a bad tradeoff, and SB is a needlessly strict nightmare with no equivalent to unique_ptr supplying RAII deallocation without noalias semantics). Though it is wise to be cautious in C++ around objects with self-pointers (unsafe to move) or aliasing member pointers (tricky lifetime constraints).