Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-12-15 19:04:35

On Thu, Dec 15, 2016 at 3:36 PM, Gavin Lambert <gavinl_at_[hidden]>
wrote:

> On 15/12/2016 20:46, Niall Douglas wrote:
>
>> Also, I'm not sure about other compilers, but with MSVC thrown
>>> exceptions always carry a stack trace with them anyway; it's possible to
>>> extract the stack trace from any exception with some platform-dependent
>>> code (without any decoration on the throw -- and depending on build
>>> options, it can even work for null references and other CPU exceptions,
>>> although some misguided people dislike that).
>>>
>>
>> I was not aware that this is the case except when /EHa is used.
>> Indeed, I had thought one of the big optimisations of /EHs was
>> precisely the fact that backtraces are *not* captured, thus making
>> C++ exception throws vastly faster than Win32 structured exception
>> throws and the point of using /EHs.
>>
>
> I don't think so.  The docs simply indicate that it reduces the locations
> where it captures unwind info and does some checks.  This does increase
> performance by reducing code size (and thus the working set) and removing
> some conditional logic, but it comes at the cost of failing to execute some
> destructors if an exception does get thrown/raised. (Which is probably ok
> if the process is going to be terminated by an uncaught exception anyway,
> but less so if not.)  I didn't see anything about changing the actual
> implementation of exceptions.
>

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

Emil