Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> C++ isn't 'memory safe', but what it does is give you the ability to write memory and resource safe types, and then lean on the type system as a means of ensuring memory safety.

No, it doesn't, because it isn't memory safe.

> All this is why C++ is better than C. In C++ you can have memory safety, thread safety, type safety, and a simple API.

No, you can't. C++ is not memory safe. Use after free happens in C++ all the time, because smart pointers do not protect you from dangling pointers and null pointer dereference, among other things.

Instead of copy and pasting examples to show this, I'll just link to other posts of mine from the past two months: https://news.ycombinator.com/item?id=11111987, https://news.ycombinator.com/item?id=11054630, https://news.ycombinator.com/item?id=11055020, https://news.ycombinator.com/item?id=10819501.



Move your for-loop in to an algorithm that takes Container by const& and your resize() / iterator invalidation problem becomes a compile error. If you actually need to resize your array while you iterate, then a language like Rust is going to catch your pointer invalidation, but it's not going to make the impossible possible and suddenly make your algorithm do something sensible.

I never claimed C++ statically enforced memory safety. Clearly that can't happen while its a superset of C. I just claim that it's steadily reaching the point where the most concise and elegant code with the best API is the safest.

And I'd argue that's the problem with C. The language is too weak to write safe code concisely, so you end up with too much cognitive load, get lazy, and then end up with sprawling unauditable messes like we see in glibc lately.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: