Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Current hardware trends make C++ exceptions harder to justify

open-std.org

Post reply on HN
Print view View original

271–280 of 516 posts

Re: Current hardware trends make C++ exceptions harder to justify

#271

Post by gpderetta »

zozbot234 wrote: post #86
edflsafoiewq wrote: post #72

Earlier quoted context omitted.

My problems with Result/expected/etc 1. They generate syntactic noise at every point they touch the call graph: function signatures, calls, returns. 2. In particular, if a change causes a deeply nested function that used to always succeed to be able to error, the entire path up the call graph needs to get Resultified. 3. Since the caller must be aware of them, generic code generally has to be Result-aware too. 4. The…

> They generate syntactic noise at every point they touch the call graph: function signatures, calls, returns. This is not "noise" but needed information. A function that can error out should not have the same signature as one that will never return an error. Similarly, call-site special syntax (like '?' in Rust) helps address the concerns raised by hidden control flow. > Since the caller must be aware of them, gener…

I agree that functions should specify in their signature wether and how they fail, but checked exceptions can do that. Additional call site syntax is indeed just noise. I strongly agree with David Abrahams[1] on this. A better solution would be noexcept regions were the compiler would statically guarantee that they can't be left via exceptional control flow.

[1] https://forums.swift.org/t/on-the-proliferation-of-try-and-s...

Re: Current hardware trends make C++ exceptions harder to justify

#272

Post by cryptonector »

gpderetta wrote: post #225
cryptonector wrote: post #220

Earlier quoted context omitted.

I agree. I'm not sure breaking the ABI to fix the unwinder serialization issue should be a show-stopper, considering that there still isn't a C++ ABI.

There are platform specific ABIs and there have been for many years. Many platforms want to preserve the ABI at all costs. In any case this doesn't seem to be an ABI issue

I would think it shouldn't be an ABI issue, but maybe part of the unwinding code gets statically linked into shared objects?

Re: Current hardware trends make C++ exceptions harder to justify

#273

Post by lanstin »

Dork1234 wrote: post #247

It would be interesting to see a breakdown of exception overhead for C++/Rust/Haskell/Julia/Swift in multi-threaded workloads. Sometimes that happens rarely but blocks many threads is a huge pain to deal with.

Just write code with a bunch of threads that are all logging a few M / second and see if the CPUs are running equally hot or 1 is 100% and the rest are mostly idle.

Re: Current hardware trends make C++ exceptions harder to justify

#274

Post by gpderetta »

lanstin wrote: post #261
wvenable wrote: post #168

Earlier quoted context omitted.

> A function that can error out should not have the same signature as one that will never return an error. Functions that never fail are pretty rare compared to ones that do. It's easier to just assume that all functions can fail. Mentally it's a much simpler model.

This post is the saddest thing I have ever read in computing. So much power comes about (on the CPU, in the call stack) by being able to assume that things proceed with mathematical tractable properties, as computable functions, plain old general recursion. Distributed things, sure, you have to have protocols and so one to regain the determinism, and even then perfection is no longer achievable, but within your big F…

Pragmatically, shit happens.

Re: Current hardware trends make C++ exceptions harder to justify

#275

Post by jcelerier »

mcguire wrote: post #171
jcelerier wrote: post #151

Earlier quoted context omitted.

> I am the the original author, and trust me, I am describing a real world problem. for a more-or-less niche part of "real world". The overwhelming majority of desktop GUI apps rely on some C++ system - Qt, gtkmm, Wx, Blink, Gecko, FLTK, etc etc... and it is not an issue for those, for what exceptions are commonly used for (a write failing because the user disconnected the USB drive while it was copying, a system res…

Are you arguing that C++ is unsuitable for massive parallel data processing tasks?

No, of course not. But let's not change the language in ways that benefits those use cases at the detriment of more common use cases.

Of course, if there are ways to keep more or less the same semantics, while increasing performance, by all means it should be done !

Re: Current hardware trends make C++ exceptions harder to justify

#276

Post by jcelerier »

jandrese wrote: post #187
mcguire wrote: post #171

Earlier quoted context omitted.

Are you arguing that C++ is unsuitable for massive parallel data processing tasks?

I think he's arguing that C++ exceptions are unsuitable for parallel data processing, at least in cases where exceptions are regularly thrown.

If exceptions are regularly thrown the software has a bad design and must be fixed. Non-exceptional stuff must of course not be handled through exceptions - no exception should ever be thrown if the software operates as it is expected to.

Re: Current hardware trends make C++ exceptions harder to justify

#278

Post by jeffbee »

kevin_thibedeau wrote: post #211
jeffbee wrote: post #9

Earlier quoted context omitted.

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.

You also have to abandon operator new and STL unless you want to pretend they never fail.

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.

Re: Current hardware trends make C++ exceptions harder to justify

#279

Post by lanstin »

_0w8t wrote: post #83
Rarebox wrote: post #53

Earlier quoted context omitted.

There's very little you need exceptions for with STL. Data structures, algorithms, etc. all work just fine without exceptions. C++ without exceptions is great. Google doesn't use exceptions and they still use STL. Gamedevs usually don't use exceptions and they're fine. Just use some other mechanism for errors, like error codes, absl::Status, std::expected, etc.

Note Google explicitly configure runtime to instantly crash on memory allocation errors. With that STL works indeed nicely without exceptions.

I interviewed at Google once and during some whiteboard forgot to check malloc for NULL return, then mentioned, "oh yeah at malloc never returns NULL" and the interviewer commented "at Google, malloc spawns a new data center."

Re: Current hardware trends make C++ exceptions harder to justify

#280

Post by layer8 »

taeric wrote: post #229
dtech wrote: post #170

Earlier quoted context omitted.

Java's checked exceptions are generally regarded as a mistake. There's a reason no other languages has them, and newer JVM languages (Groovy, Clojure, Scala, Kotlin) treat all exceptions as runtime. Anders Hejlsberg (creator of Delphi, C# and Typescript) also has an excellent article on their problems [1]. In modern Java I see nearly only runtime exceptions used, especially because that's necessary for most Java 8+ l…

I think the question is more on if the implementation of how the jvm does exceptions somehow less affected by core count? That is, the checked part is just a language implementation, right? The jvm doesn't really make much of a distinction. (This is meant as a check to my assumption.)

Yes, that's right, as static type checks generally are. However, the C++ performance issues are unrelated to whether exceptions are statically and/or runtime checked. Furthermore, Java exceptions are not particularly efficient, in particular because they collect the current stack trace on creation by default, which is a relatively expensive operation.
Post reply on HN