Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-12-14 21:01:34

On 15/12/2016 12:44, Andrey Semashev wrote:
> On 12/15/16 02:27, Peter Dimov wrote:
>> This sounds like a pretty good idea, although I'm not sure if we can
>> enable it by default as people have historically been very sensitive to
>> changes to BOOST_THROW_EXCEPTION. But an opt-in macro should be fine and
>> very useful as one would automatically get stack traces from every use
>> of BOOST_THROW_EXCEPTION. Hello Java.
>
> I've not taken a look at the proposed Stacktrace library, but from what
> I know obtaining a stacktrace is typically a rather expensive operation.
> I expect it to be no less expensive than throwing the exception. That's
> probably too much to pay for by default. Plus, it adds one more
> dependency on another library via such a core component as
> BOOST_THROW_EXCEPTION.

Capturing the stack to later perform a trace is relatively cheap and 
fast (though perhaps memory wasteful, though you usually wouldn't care 
about that unless the exception was due to running out of memory).  It's 
interpreting that data into a human-readable trace that's the slow part. 
  And I've previously asked about this and been assured that this 
library does do this in two separate phases to reduce performance impact 
at the trace site.

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 haven't looked at this library in detail yet so I don't know if it 
takes advantage of this or not.