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

91–100 of 516 posts

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

#91

Post by andi999 »

ModernMech wrote: post #51
nly wrote: post #6

Earlier quoted context omitted.

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 maintain…

How do you get memory without new nowadays?

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

#92

Post by chippiewill »

Someone wrote: post #47

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/…

The article discusses this.

RW lock is an option that helps but involves breaking the ABI of EVERY shared library.

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

#93

Post by henrydark »

grandinj wrote: post #90

Counterpoint: I do a lot of perf work on LibreOffice, which makes extensive use of exceptions, and I have never ever even seen the exception throwing show up on a profile, let alone become a problem. I think this paper started with a conclusion, and worked backwards to justify it.

As per the piece, open 128 documents on a 128 core machine, and you'll see the difference.

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

#94

Post by _0w8t »

CyberRabbi wrote: post #13

I am glad more people are raising the issue with C++ exceptions. Unfortunately I don’t think the argument made in this article is compelling enough. Bjarne is against replacing the current model and has written an entire article responding to various criticisms of the current model. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p194... In particular he has already responded to the efficiency argument with t…

If the current model stays in place, then there would be no possibility to reconcile the de-facto fork of C++ into code disabling exceptions and code using it with the former can be running on more CPUs than the latter. In turn that leads to monstrosity like file system access API that try to have exception and exception-less versions of each function.

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

#95

Post by mhh__ »

grandinj wrote: post #90

Counterpoint: I do a lot of perf work on LibreOffice, which makes extensive use of exceptions, and I have never ever even seen the exception throwing show up on a profile, let alone become a problem. I think this paper started with a conclusion, and worked backwards to justify it.

This is mostly my opinion too.

My argument against exceptions is basically everything other than performance. To make a performance decision you have to build the code incrementally with feedback from how it is actually going to be used e.g. if almost every parse fails then you probably don't want to throw whereas if your code almost always succeeds you probably want your register back (i.e. use exceptions)

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

#96

Post by kccqzy »

edflsafoiewq wrote: post #72
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…

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…

> 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.

This is a pro not a con. It now shows clearly that all these function calls are now failable. Of course at higher levels you may have additional assumptions that you know won't make the low-level functions fail, and you are welcome not to change everything as well.

> 4. They aren't a total solution, exceptions usually have to exist anyway (eg panic), for things like oom/assert/etc. So you're usually paying the cost of them anyway.

Panics do not need to be caught and handled. You can (and should) transform panics into abort.

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

#97

Post by kaetemi »

andi999 wrote: post #91
ModernMech wrote: post #51

Earlier quoted context omitted.

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 maintain…

How do you get memory without new nowadays?

make_unique, etc.

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

#98

Post by mhh__ »

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.

Memory allocation is the big think that new players often miss.

A lot of time I see people saying D is unusable (excitedly) for a certain usecase, and you know what if you use the GC a lot it might be, but then I then see them write code that uses raw malloc and free willy nilly. GC can bite you in the ass, but so will basically all memory allocation if you don't understand the real trends of your program i.e. "Nature is a language, can't you read?"

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

#99

Post by superjan »

Someone wrote: post #47

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/…

It is avoidable by using locks like you mention, the article actually says so, but it causes an ABI change. They go on to say that this makes it undesirable, but compared to what alternative exactly?

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

#100

Post by alskdjflaskjdhf »

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.

Yep, these are used extensively at Google (which is where the abseil library came from, and which is famously anti-cpp-exceptions) and they work very well. If I somehow found myself writing a new C++ project I'd probably reach for abseil (and some of the other parts of the Google toolchain: GoogleTest for testing, bazel for builds).
Post reply on HN