11–20 of 516 posts
That's why we disable exceptions in video games.
There are tons of games where exceptions are perfectly fine. Though still more often used for "probably going to crash soon" situations than otherwise, I'd wager.
In particular he has already responded to the efficiency argument with the counter argument that current implementations can be optimized. Even if that optimization process breaks ABI compatibility, it’s still better than breaking source compatibility, which is usually what is being proposed. He is right about that so I don’t think efficiency arguments are going to sway him.
I used to embrace C++ exceptions until I had to use C++ in non-conventional environments. For me C++ exceptions are wholly inappropriate for real-time programming since it’s difficult to statically quantify how much time an exception handling sequence may take. There’s also the issue of it requiring malloc() which has its own issues from an interface standpoint in the real-time context. To avoid unbounded malloc, you’d have to set aside a per-thread area for exception storage and require that you never throw an exception value past a certain size.
Wouldn’t changing the global mutex into a read/write be a simple way to fix things? Shared libraries changing the exception table at the same time as exceptions being thrown seems rare. Might also be fixable in an API-preserving way… Edit: nope. This idea is discussed later in the paper (not fully ruled out but the answer may still require ABI changes for more subtle reasons)
Wouldn’t changing the global mutex into a read/write be a simple way to fix things? Shared libraries changing the exception table at the same time as exceptions being thrown seems rare. Might also be fixable in an API-preserving way… Edit: nope. This idea is discussed later in the paper (not fully ruled out but the answer may still require ABI changes for more subtle reasons)
I'm really heartened in the last few years that FP popularity has caused more people to avoid exceptions and even golang doesn't support them.
> 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…
> 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…
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.