undefined | Better HN

0 pointsquotemstr10y ago0 comments

> Sure, but if linux has this issue, then C++ programs on linux will also have this issue

Why even bring Linux into the discussion? A Rust program running on Windows has the same problem.

> No. My point was simply that no language has a complete solution to this problem.

A correct C++ program running on Windows will not spuriously abort. Neither will a C++ program running on a Linux system configured not to overcommit. That some Linux systems can be configured to kill processes at arbitrary times is not an excuse for Rust to be sloppy with memory allocation.

C++ and many other languages do, in fact, have complete solutions to this issue, and that Rust does not is a serious deficiency, one serious enough to prompt me to prefer other languages despite Rust's other advantages.

0 comments

lambda10y ago

Can you point to an example of such a "correct C++ program" that is larger than some sample code or a toy program demonstrating this technique?

I'm just wondering if this argument is all hypothetical, or if there are any teams of C++ programmers who are actually disciplined enough to be able to handle this case in practice, in large scale software. I know that in most code that I've seen, the only use of std::bad_alloc has been to log the error and abort.

Rusky10y ago

...and the same is true of Rust, just with different defaults. Switch allocation failure from an abort to a panic and catch the panic just like you would in C++.

What's incomplete about that? It's not like C++ can't be switched in the other direction with -fno-exceptions or equivalent.

quotemstrOP10y ago

-fno-exceptions is not part of C++. C++ is not whatever GCC and Clang happen to accept.

j / k navigate · click thread line to collapse