[alpire]

> its trivial to write memory safe C++

It is not unfortunately. That's why we see memory safety being responsible for 70% of severe vulns across many C and C++ projects.

Some of the reasons include: - C++ does little to prevent out-of-bounds vulns - Preventing use-after-free with smart pointers requires heavy use of shared pointers, which often incurs a performance cost that is unacceptable in the environment C++ is used.

[Dylan16807]

> It is not unfortunately. That's why we see memory safety being responsible for 70% of severe vulns across many C and C++ projects.

I don't think that's really a rebuttal to what they're trying to say. If the vast majority of C++ devs don't follow those two rules, then that's not much evidence against those two rules providing memory safety.

[adgjlsfhk1]

Right but the reason they don't follow those 2 rules is that using them would require not using most C++ libraries that don't follow the rules, and would introduce performance regressions that negate the main reason they chose C++ in the first place.

[Dylan16807]

This entire post is about a gradual transition. You don't have to avoid libraries that break the rules, you just have to accept that they're outside the safe zone.

For performance, you'll have to be more specific about your shared pointer claims. But I bet that it's a very small fraction of C++ functions that need the absolute best performance and can't avoid those performance problems while following the two rules.