4 ms·

Modern C++ isn't really safe. Safe means the compiler catches you, generally C++ compilers don't. Trivial example is iterator invalidation -- even with all warn

Modern C++ isn't really safe. Safe means the compiler catches you, generally C++ compilers don't. Trivial example is iterator invalidation -- even with all warnings and errors on compilers don't catch it.

lelanthran 4y ago
> Modern C++ isn't really safe. Can we cut it out with the hyperbole? Using "It Isn't Really Safe Unless It Is Written In My Favourite Niche Language" as an argument is .. well ... ridiculous. You can extend that argument to any practical programming language. So ... Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted, where your application deadlocks, or threads starve, etc. Haskell ... "Isn't Really Safe" because it is not possible to formally verify the logic. Etc, ad infinitum ... Maybe go for "Not As Safe As". After all, I don't even like C++ (see my comment history), but it's certainly possible (and not very hard) to get about 90% of Rust safety in C++. Safety is not a binary, it's on a spectrum. Saying that a language is either safe or unsafe implies that the "safe" language is actually safe while the "unsafe" language is completely deadly. That's certainly not true.
- kobebrookskC3 4y ago
  > Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted i dare you to find memory corruption in safe rust that isn't already on an issue tracker. > Saying that a language is either safe or unsafe implies that the "safe" language is actually safe while the "unsafe" language is completely deadly. tell that to the people who got owned by https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... , most likely human rights activists targeted by less-than-savory regimes. memory corruption bugs are so frequent that it is possible for nso group to sell to pretty much any regime, and not forced to be classified as top secret information.
  - cozzyd 4y ago
    > i dare you to find memory corruption in safe rust that isn't already on an issue tracker. can't you just mess around with /proc/self/mem :)
    - steveklabnik 4y ago
      That one was already reported to the tracker :) https://github.com/rust-lang/rust/issues/32670 https://github.com/rust-lang/rust/issues/32670 (To be clear, I’m not saying that there’s no issues that aren’t in the tracker yet. But there are a bunch of them that are. More will absolutely be found as time goes on, that’s just how these things are.)
      - cozzyd 4y ago
        Thanks, that was an amusing read!
pjmlp 4y ago
Not a Visual C++ user I imagine, because that is exactly what enabling _ITERATOR_DEBUG_LEVEL does.
coderenegade 4y ago
So we should all be using Spark Ada? Safety isn't an all or nothing thing, and in most cases, rigorous safety comes with tradeoffs. In some applications those tradeoffs are worth it, and in others they're not. A small project probably doesn't need to be provably correct, because it's easy enough to analyze it, and you aren't gaining much if the more rigorous language is unwieldy (they often are); similarly, a large enterprise project is harder to analyze, and has larger costs if there are CVEs, so a safer language is probably a good fit. Note that this doesn't necessarily mean rust, though -- garbage collected languages sit here, too. Rust sits in the niche of "big enough and / or critical enough to justify rigorous safety", and "high performance really matters".

lelanthran 4y ago

> Modern C++ isn't really safe. Can we cut it out with the hyperbole? Using "It Isn't Really Safe Unless It Is Written In My Favourite Niche Language" as an argument is .. well ... ridiculous. You can extend that argument to any practical programming language. So ... Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted, where your application deadlocks, or threads starve, etc. Haskell ... "Isn't Really Safe" because it is not possible to formally verify the logic. Etc, ad infinitum ... Maybe go for "Not As Safe As". After all, I don't even like C++ (see my comment history), but it's certainly possible (and not very hard) to get about 90% of Rust safety in C++. Safety is not a binary, it's on a spectrum. Saying that a language is either safe or unsafe implies that the "safe" language is actually safe while the "unsafe" language is completely deadly. That's certainly not true.

kobebrookskC3 4y ago
> Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted i dare you to find memory corruption in safe rust that isn't already on an issue tracker. > Saying that a language is either safe or unsafe implies that the "safe" language is actually safe while the "unsafe" language is completely deadly. tell that to the people who got owned by https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... , most likely human rights activists targeted by less-than-savory regimes. memory corruption bugs are so frequent that it is possible for nso group to sell to pretty much any regime, and not forced to be classified as top secret information.
- cozzyd 4y ago
  > i dare you to find memory corruption in safe rust that isn't already on an issue tracker. can't you just mess around with /proc/self/mem :)
  - steveklabnik 4y ago
    That one was already reported to the tracker :) https://github.com/rust-lang/rust/issues/32670 https://github.com/rust-lang/rust/issues/32670 (To be clear, I’m not saying that there’s no issues that aren’t in the tracker yet. But there are a bunch of them that are. More will absolutely be found as time goes on, that’s just how these things are.)
    - cozzyd 4y ago
      Thanks, that was an amusing read!

pjmlp 4y ago

Not a Visual C++ user I imagine, because that is exactly what enabling _ITERATOR_DEBUG_LEVEL does.

coderenegade 4y ago

So we should all be using Spark Ada? Safety isn't an all or nothing thing, and in most cases, rigorous safety comes with tradeoffs. In some applications those tradeoffs are worth it, and in others they're not. A small project probably doesn't need to be provably correct, because it's easy enough to analyze it, and you aren't gaining much if the more rigorous language is unwieldy (they often are); similarly, a large enterprise project is harder to analyze, and has larger costs if there are CVEs, so a safer language is probably a good fit. Note that this doesn't necessarily mean rust, though -- garbage collected languages sit here, too. Rust sits in the niche of "big enough and / or critical enough to justify rigorous safety", and "high performance really matters".