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

41–50 of 516 posts

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

#41

Post by masklinn »

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…

One of the core problems is C++’s design basically requires it: there’s no other way to error from a ctor, and since ctors are used as hooks in many operations the dishonest rejoinder of “just use a factory” doesn’t work in any capacity.

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

#43

Post by kirbyfan64sos »

jkaptur wrote: post #17
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'm relatively new to C++ and I found absl::StatusOr and its helper macros to be extraordinarily pleasant.

It has helper macros now? I liked StatusOr but had to write my own helper macros for it at the time.

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

#44

Post by worik »

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.

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

#45

Post by roger10-4 »

worik wrote: post #39
rossmohax wrote: post #20

If not exception, then how to fail constructor?

It has been many years since I used C++ But returning null is an obvious choice. Combined types which return the structure or an error are another. Has the advantage of returning error information, why failure. There are many ways

You can’t return null from a constructor (constructors have no return)

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

#46

Post by cyber_kinetist »

worik wrote: post #31
erwincoumans wrote: post #23

I always avoid C++ exceptions, and also try to avoid dynamic memory allocations, smart pointers and RTTI etc whenever possible. This is pretty common in latency and (pseudo) real-time performance critical work, such as robotics control and 3d gaming.

Why do you use C++ in those domains? Curious as to the decision criteria.

If you need any sort of numerical programming, C++ is basically unmatched. It's fast and efficient (have total control over memory and heap allocations), while able to create complex math abstractions thanks to its template system and operator overloading.

For example, Eigen is the only library (not in C++, but in the entire programming space) that can optimize your math expressions at compile-time. You can also perform techniques like auto-differentiation by using templates. Meanwhile, Rust still doesn't have full const generics, which are needed to create a math library that's both efficient and easy to use (nalgebra still depends on typenum, which is much uglier than even the most esoteric C++ template stuff you can find!)

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

#47

Post by Someone »

FTA: The root cause is that the unwinder grabs a global mutex to protect the unwinding tables from concurrent changes from shared libraries

Is it unavoidable that that hurts performance badly for the common case? I would think such concurrent changes are rare, so if there’s an asymmetric way to protect against that that’s faster in the happy path exists, that would be a big improvement.

https://en.wikipedia.org/wiki/Readers–writer_lock mentions Read-preferring RW locks, but (from cursory reading) doesn’t say how much that can help.

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

#48

Post by _b »

I think the dilemma for C++ exceptions is that if the programmer actually thinks something should never happen, it is almost always better to just crash. But if the programmer thinks it might happen sometimes, then it is risky to predict it is will be super rare, as often this code will be called in different contexts in the future, so it is safer to use normal returns and flow control. As a result, throwing an exception is basically never the best thing to do.

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

#49

Post by masklinn »

tsimionescu wrote: post #8

Very interesting that exceptions have much less overhead on the happy path than Rust/Haskell style Either types (std::expected): > For fib we see a slowdown of approx. 60% compared to traditional exceptions, which is still problematic.

> Very interesting that exceptions have much less overhead on the happy path than Rust/Haskell style Either types

C++ genuinely traded “error” cases (made them even costlier) so that the happy path of exceptions would be cheaper. I don’t remember whether that’s the case in C++, but in some language/implementations (used to be a big issue in V8) just having a try/except would drastically deoptimise a function, even if the exception never happened.

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

#50

Post by Calavar »

worik wrote: post #39
rossmohax wrote: post #20

If not exception, then how to fail constructor?

It has been many years since I used C++ But returning null is an obvious choice. Combined types which return the structure or an error are another. Has the advantage of returning error information, why failure. There are many ways

> But returning null is an obvious choice.

It's not because C++ is not an everything-is-a-reference language.

> Combined types which return the structure or an error are another. Has the advantage of returning error information, why failure.

Sum types are great, but changing constructors to return sum types would break all existing code. It would also lead to a whole slew of questions about how the construction of arrays of values would work. (Does an array of an objects now turn into an array of wrapper types? Byebye SIMD optimization!) It would also break the consistency of constructing POD vs non POD types, which would make writing templates that need to generalize over both a huge PITA.

Post reply on HN