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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk