Hacker News Reader

Comment by Animats | Hacker News Reader

"Now, we can extend our allocation model with a few additional guidelines, and as long as we’re following these rules/ guidelines, our C++ programs WILL become perfectly safe against memory corruptions."

What could possibly go wrong?

View on HN

If you're not being facetious, then really, not much. You really can't go wrong with smart pointers unless you explicitly try to access the memory it handles rather than going through its normal interface (e.g., not using get()). Shared pointers are basically reference counted just like many other language handle memory management.

> > as long as we’re following these rules/ guidelines

If that's an assumption, it's not worth much. A safe language is one that enforces the rules, not one that hopes the program authors self-enforce.

I don't think anyone claimed the _language_ was safe.

Title: "A Usable C++ Dialect That Is Safe Against Memory Corruption".

Any questions?

The author claims that the rules described, "extending" the standard C++, are enforcing memory corruption, and it is this author described subset that is still unsafe, not C++ in general. Think about english vs. americanized english, largely the same, but two distinct entities.

In C++, you are free to shoot yourself in the foot. In Rust, you have a Government inspector ensure that you always point the gun not just in a "safe" direction, but only toward a crosshair target at a designated gun range.

Of course. The point is that (IF there is enough interest in the idea) these rules are simple enough (in particular, they're inherently local, i.e. don't require analysis to go beyond one single function) to be enforced by a tool (say, built on top of Clang-tidy).

By that measure Rust would be unsafe since it hopes that the authors don't just put everything in unsafe blocks.

Reply on news.ycombinator.com