4 ms·

Computer science programs used to teach variations of C/C++. Last I checked where I went as well as talking to junior engineers I have worked with. You can ge

Computer science programs used to teach variations of C/C++. Last I checked where I went as well as talking to junior engineers I have worked with. You can get through a whole CS program at a dop 50 university without touching the language. There have been debates here about C/C++ being "dangerous". And it can be, if you don't know how to use it. I recall discussions where doing in-line assembly in C had a similar discussion. It doesn't take being an "expert". It does take "understanding what you are doing" but that same thing applies regardless of the language/tool/etc.

criddell 4y ago
The depth of what you want to understand with C++ is sometimes pretty deep though. I’m thinking about things like lvalues, rvalues, const vs constexpr, etc…
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).
oconnor663 4y ago
When the problem is "understanding what you are doing" it's not so bad. But often the problem is more like "understand what everyone around you has done". If they shared an object across threads, then you can't do mutation without a lock. If they retained a reference into your vector, then you can't grow it. It's this sort of invisible UB at a distance that gets so hard to deal with as projects get larger, even between experts.

criddell 4y ago

The depth of what you want to understand with C++ is sometimes pretty deep though. I’m thinking about things like lvalues, rvalues, const vs constexpr, etc…

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).

oconnor663 4y ago

When the problem is "understanding what you are doing" it's not so bad. But often the problem is more like "understand what everyone around you has done". If they shared an object across threads, then you can't do mutation without a lock. If they retained a reference into your vector, then you can't grow it. It's this sort of invisible UB at a distance that gets so hard to deal with as projects get larger, even between experts.