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

51–60 of 516 posts

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

#51

Post by ModernMech »

nly wrote: post #6
jmyeet wrote: post #3

> Root cause > Traditional C++ exceptions have two main problems: > 1) the exceptions are allocated in dynamic memory because of inheritance and because of non-local constructs like std::current_exception. This prevents basic optimizations like transforming a throw into a goto, because other parts of the program should be able to see that dynamically allocated exception object. And it causes problems with throwing ex…

std::expected doesn't require language changes, it's a library type. If anything it shows how C++ is multi-paradigm

This is the great strength and weakness of C++. Increasingly the answer to C++'s rough edges is "We don't do things that way anymore. Everyone does X now", where X is the hot new thing. RAII is the best example I can think of, where some people insist that no one would ever use the "new" and "delete" keywords anymore. Except for all the C++ devs that do, and all the C++ code that exists that does and must be maintained.

It leads to the current situation where you have C++ "the language" which is everything, and then C++ "the subset that everyone uses" where that subset constantly changes with time and development context.

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

#52

Post by masklinn »

ziml77 wrote: post #34

I find this analysis strange. Yes, C++ does need ergonomic ways to return an error without dynamic allocation (Rust's magic of ? combined with the From/Into traits is nice), but I don't know why you'd analyze the performance impact when you have many failures. If a failure is that common, then you aren't supposed to be using exceptions. It's not really an exceptional circumstance at that point.

> I don't know why you'd analyze the performance impact when you have many failures. If a failure is that common, then you aren't supposed to be using exceptions.

The problem is in that case you get into a probabilistic estimation, which is a nice way to say you roll the dice on your performances: what’s the ratio at which exceptions are too costly or sufficiently cheap? And how does that impact your level of service if e.g. exceptions are extremely rare but they tend to all affect the same request or workload?

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

#53

Post by Rarebox »

synergy20 wrote: post #38

C++ STL is a strong selling point for c++, disabling exceptions mean you lose all of STL in the library, unless you're fine to use STL without any error reporting at all. In the gaming case(no rtti, no smart pointer, no exceptions(thus meaning ctor|dtor are "unsafe")), what else do you leave with c++ then? I use c++ but I'm always struggling with yes-or-no for exceptions. c++ is deeply rooted with exceptions, bad or…

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.

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

#54

Post by InfiniteRand »

jeffbee wrote: post #36
jdlshore wrote: post #30

Earlier quoted context omitted.

There are some kinds of errors that can’t be handled locally, but do need to be handled globally, or generically higher in the call chain. Continuing execution after the error occurs will make the problem worse. Exceptions allow you to cease execution without putting an if statement after every function call.

That's what you get from disabling exceptions: a call to std::abort instead of a throw.

In some ways that’s throwing an exception into the calling environment in the form of an error code

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

#55

Post by synergy20 »

forrestthewoods wrote: post #10

> Nevertheless the overhead is so high that std::expected is not a good general purpose replacement for traditional exceptions. This is basically the path Rust has chosen. I’m curious if it’s _actually_ too slow for C++. I feel like the answer must be no.

same as golang, I doubt that causes serious performance issues but have no proof.

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

#56

Post by Thaxll »

Negitivefrags wrote: post #28
Thaxll wrote: post #2

That's why we disable exceptions in video games.

We disable exceptions in video games due to lock contention when throwing exceptions on multiple threads in high core count situations? No. We disable exceptions in video games for dumb historical reasons that no longer apply.

Dumb? https://www.youtube.com/watch?v=GC4cp4U2f2E

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

#57

Post by masklinn »

fbkr wrote: post #7
jmyeet wrote: post #3

> Root cause > Traditional C++ exceptions have two main problems: > 1) the exceptions are allocated in dynamic memory because of inheritance and because of non-local constructs like std::current_exception. This prevents basic optimizations like transforming a throw into a goto, because other parts of the program should be able to see that dynamically allocated exception object. And it causes problems with throwing ex…

I've been using `expected`, i.e. value-or-error type, for a while in C++ and it works just fine, but the article shows it has some noticeable overhead for the `fib` workload for instance. Not sure if the Rust implementation has a different design to make it perform better though.

> Not sure if the Rust implementation has a different design to make it perform better though.

Prolly not, I expect the issue comes from the increase in branches since a value-based error reporting has to branch on every function return. Even if the branch is predictible, it’s not free.

And fib() would be a worst-case scenario as it does very little per-call, the constant per-call overhead would be rather major.

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

#58

Post by synergy20 »

RcouF1uZ4gsC wrote: post #24

> It breaks the existing ABI, and all shared libraries would have to be compiled with the new model, as otherwise unwinding breaks. I am convinced that maintaining ABI is a huge technical debt to C++. And that is largely occasioned by shared libraries. Rust IMO made a fantastic decision to emphasize source distribution (and making it super easy via cargo and crates).

you do pay the compilation time price though, sometimes it takes really a long time to rebuild.

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

#59

Post by CyberRabbi »

john567 wrote: post #27

Why do we need to have ambient control flow? This is what exception handling is, it's a hidden control flow. I don't use them. I just create an error type and pass that around. The only legitimate exception I will accept is when you access invalid memory. That's a special case and depending on the environment something extraordinary must happen. But exceptions and exception handling just creates annoying code. It doe…

> The only legitimate exception I will accept is when you access invalid memory.

If all memory accesses were done with a function call, e.g. read(void *addr), then by your logic there would be no legitimate need for exceptions.

If you extrapolate into the other direction, exceptions are convenient from a syntactic POV because it avoids littering every operation with an explicit error return mechanism.

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

#60

Post by criddell »

worik wrote: post #44

Begs the question: Why C++? Legacy projects (I am not being pejorative, they are important) which must be maintained aside, should not C++ be deprecated? We have many new languages, we always had C. What does C++ give us in 2022 that makes up for the enormous cognitive load of understanding and keeping up with it.

Believe it or not, there are a lot of us who enjoy C++ and think the language is getting better all the time. IMHO, it's a pretty good time to learn C++.

As for what do you get? Well, compared to C you can get higher programmer productivity and compared to any language other than C, you get great performance.

Post reply on HN