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.