44 ms·
I admittedly don't write much C++ and what I do know is largely limited to C++03. But it does flummox me a bit that C++ keeps getting lumped in with C. Aren't `
by kbolino 3y ago
I admittedly don't write much C++ and what I do know is largely limited to C++03. But it does flummox me a bit that C++ keeps getting lumped in with C. Aren't `std::vector` and `std::string` bounds-checked? Isn't it possible, though perhaps not always obvious or ergonomic, to write memory-safe C++ code? It seems like improving static validation tools might be more useful than trying to phase out C++.
I also think the build system and dependency management could probably use at least as much attention as memory safety, though maybe there's some convention that's emerged lately which brings it in line with more recent languages.
- im3w1l 3y agostd::vector is bounds checked if you use .at() instead of operator[]. But it's less ergonomic and I don't think people typically use that.
- kbolino 3y agoGood point. I would think you could make operator[] bounds-checked with an opt-in mechanism like a #define but I don't know if such a thing exists and I would assume it could cause unpredictable behavior in code not designed to handle exceptions. Thinking about this example, it seems like the other problem is that even when bounds-checked, C++ code handles out-of-bounds conditions by throwing exceptions, which seem to have a bad rap in C++.
- gpderetta 3y ago_GLIBCXX_ASSERTIONS which is explicitly intended to be enabled for production builds.
- im3w1l 3y agoI actually disagree with that. Exceptions have their problems when used for error handling, but they are a great solution for error not-handling, and normally index out of bounds is a bug that you can't / don't want to recover from. Exceptions will bubble up and unwind the stack, cleaning things up by running destructors. In other languages they will also display a nice little backtrace, though in c++ it seems thats not typically done for reasons that are beyond me.
- kbolino 3y agoYeah, I've got more experience lately with Go and Rust, where as you say, error not-handling is an acceptable fallback for unintentional mistakes via panic. I'm not sure what the practical differences are between C++ exceptions and Rust/Go panics though, apart from the lack of backtrace.
- gpderetta 3y agoOr you if you flip the correct compiler flags.
- packetlost 3y agoC++ is so large that choosing the safe subset is completely non-obvious unless you're deeply experience in the language already.
- bombcar 3y agoAnd with similar knowledge and care, C can also be safe; after all, memory safe languages can be written in C.
- kbolino 3y agoYeah, my thought/question is more about doing so ergonomically. Because C++ has encapsulation and operator overloading, you can make it very ergonomic to write memory-safe code. I think it's very difficult to do the same with plain C. It's probably possible to make it less painful with macros, but doing so builds something more like a DSL atop of C, and would frustrate IDEs that don't understand the conventions.
- MaxBarraclough 3y ago> C can also be safe In practical terms, no, it cannot. Even C codebases held to very high standards tend to have memory-safety issues. > memory safe languages can be written in C That says nothing about the safety of the C language.
- secondcoming 3y agoThese days it’s surprisingly hard to write memory-unsafe C++ code for not-so-trivial programs. There are still things that can trip you up, like views.