On 12/15/16 05:01, Gavin Lambert wrote:
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.
If that's the case then it would be nice to have some benchmark results before we impose that cost on everyone using BOOST_THROW_EXCEPTION. From my understanding (please, correct me if I'm wrong), even if you don't interpret the stacktrace, just to obtain it one has to iterate through the stack frames up to the beginning of the stack or some limit (which is not currently specified in BOOST_THROW_EXCEPTION). This has a linear complexity on the call depth. Throwing the exception, OTOH, is linear on the number of stack frames that need to be unrolled, plus other overhead such as exception construction and automatic variable destruction. Arguably, the latter complexity is typically less than the former, or the same in the worst case.