On 16/12/2016 13:04, Emil Dotchevski wrote:
The overhead in structured exception handling comes from translating hardware exceptions to C++ exceptions. Under this (quite stupid) model, the compiler has to generate code that is able to throw C++ exceptions if any arbitrary instruction happens to crash (instead, obviously, in C++ only the throw keyword can throw and exception.)
Which is what I said. I don't agree that it's necessarily stupid, though (though I do agree that it's more work). All it really boils down to though is more possible unwind state permutations (one per variable rather than one per throwable point), not really much in the way of additional code. It's not even really that much different from what it would have to do anyway in the presence of noexcept(false) constructors, which are still the majority case. It's a much better design than using signals for that, especially if your application does have a sensible way to recover from that (because you know that destructors will actually be called properly) and if the consequences of letting the application crash are worse than letting it abandon a failed task and move on. For most general-purpose applications, sure, it's usually better to just crash. As with any other feature, though, it's open to abuse and misuse by developers who don't know better, which can colour things inappropriately. (I would argue that signals are more easily misused, however, given how often people call signal-unsafe functions from a signal handler.)