News for hackers. Stuff that matters.

A comment on Current hardware trends make C++ exceptions harder to justify. Parent comment

Re:Current hardware trends make C++ exceptions harder to jus... by jeffbee on Tuesday February 22, 2022 @01:19PM (#30431387)
You don't have to start over with the whole language. Just use -fno-exceptions in your project and dictate the use of std::optional, or absl::StatusOr, or whatever your favorite variant return type may be. For the examples in the article, it may be perfectly fine to not support failure, to simply std::abort whenever the sqrt of a non-positive is requested and rename the function sqrt_or_die.
[ Parent | on HN ]
Re:Current hardware trends make C++ exceptions harder to jus... by jmyeet on Tuesday February 22, 2022 @02:00PM (#30432036)
Except if that's incompatible with libraries you're using.

For the record, I like absl::StatusOr<>.

[ Parent | on HN ]
Re:Current hardware trends make C++ exceptions harder to jus... by kevin_thibedeau on Tuesday February 22, 2022 @03:31PM (#30433302)
You also have to abandon operator new and STL unless you want to pretend they never fail.
[ Parent | on HN ]
Re:Current hardware trends make C++ exceptions harder to jus... by jeffbee on Tuesday February 22, 2022 @04:35PM (#30434186)
Right, I use an allocator that just aborts. Imagining your program can recover from alloc failures has always struck me as fanciful, or at least out of the realm of my experience.
[ Parent | on HN ]
Re:Current hardware trends make C++ exceptions harder to jus... by Inityx on Tuesday February 22, 2022 @05:50PM (#30434997)
It's a legitimate thing in embedded and other memory-constrained circumstances, when you have something like a large cache and an allocation failure can trigger manual pruning or GC.
[ Parent | on HN ]
Re:Current hardware trends make C++ exceptions harder to jus... by pjmlp on Wednesday February 23, 2022 @05:06AM (#30439561)
Just use the no_throw variant, no need to abandon new.
[ Parent | on HN ]