5 ms·
C++ doesn't have to be unsafe anymore, as it now has features that make it just fine to use without manual memory control.
by netr0ute 4y ago
C++ doesn't have to be unsafe anymore, as it now has features that make it just fine to use without manual memory control.
- augusto-moura 4y agoWell, until the statistics numbers change this idea is just on the opinion realm. Maybe it's better now, but the numbers don't lie
- netr0ute 4y agoI would bet $1 that 99% of memory leaks are from legacy C, or C++ where the code monkey forgot to use memory safe features.
- dagmx 4y agoMemory leaks aren’t safety issues
- tonto 4y agodenial of service can exploit some memory leaks i imagine
- Hemospectrum 4y agoMemory leaks are bad, but they can't break type safety. Buffer overflows and use-after-free are categorically more dangerous.
- dagmx 4y agoIn that scenario a memory leak isn’t any more unsafe than any other program data that’s in memory.
- insanitybit 4y agoIgnoring that memory leaks are not the issue, no, indeed new bugs are introduced to kernel code constantly.
- School-Cotton 4y agoThe difference is that Rust is safe by default. The `unsafe` keyword serves as documentation that the code it applies to should be reviewed extra carefully for soundness. C++ on the other hand is unsafe by default, and all code must be reviewed extra carefully to verify soundness. Unless of course you wrote linters to prevent anyone from using constructs that can possibly be used unsafely without a manual “I know what I’m doing” override, but I think despite all the recent progress in static analysis this still isn’t possible
- maccard 4y agoIt also has modern features that appear safe at first glance, but are dangerous: std::string_view make_view(const std::string& in) { return in; } Is an absolute minefield, as is: std::vector<int> vec = {1, 2}; std::span<int> sp = vec; vec.push-back(3); These are using safe, modern C++ techniques that are designed to help catch errors, but are still absolutely lethal.
- pjmlp 4y agoI just got to learn a couple of new ones, looking forward to Meeting C++ 2022 keynote from Nicolai Josuttis. Basically all the ways that ranges::view can go wrong and even trigger UB.
- mk89 4y agoThe first case is at least documented that it's the programmer's responsibility that the view should not outlive the object pointed to. Finally, the address sanitizer helps you with that, however I wonder how many actually do use sanitizers? Overall, I agree that something could have been done to prevent temporary objects at all. From my newbie point over view, it seems the standard API has the tendency to be lower level rather than ergonomic: it's up to you to know how to use it (and fuck up with it). Quite sad, because that kind of makes the language more difficult to use than it should be. I don't have enough knowledge, and I wonder if making the constructor on (const std::string&&) private/deleted would have been enough to prevent it? The second case I guess the principle is similar. Not sure if the sanitizer finds the error there, but still scary.
- ordu 4y agoThere is a discussion that without rust's move semantics C++ cannot reach the safety levels of Rust. But rust's move semantic cannot be brought to C++ without breaking an existing code.[1] In a short, C++ approach is to give any object a "blank state" which it must turn into after the value was moved from it. It is an attempt to track state "value was moved out" dynamically. Rust tracks it statically by treating a variable whose value was moved out as uninitialized variable and ensuring that are no accesses to uninitialized variables. [1] https://www.thecodedmessage.com/posts/cpp-move/ https://www.thecodedmessage.com/posts/cpp-move/
- IshKebab 4y agoIt has a load of features that help with safety but it's just not remotely on the same level as Rust.