Boost logo

Boost :

Subject: Re: [boost] [Stacktrace] review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-12-16 16:11:01

On Fri, Dec 16, 2016 at 12:24 PM, Andrey Semashev <andrey.semashev_at_[hidden]
> wrote:

> On 12/16/16 22:32, Emil Dotchevski wrote:
>> On Fri, Dec 16, 2016 at 1:20 AM, Andrey Semashev <
>> andrey.semashev_at_[hidden]>
>> wrote:
>> the argument wouldn't be whether or not capturing the
>>>> stack trace is integrated into boost::throw_exception, but whether or
>>>> not
>>>> it is enabled by default. Either way, the boost::exception class
>>>> (defined
>>>> in boost/exception/exception.hpp) should provide a hook for that
>>>> integration in order to avoid coupling between boost::throw_exception
>>>> and
>>>> Stacktrace.
>>> The way I see it, boost::exception already provides everything needed,
>>> which is the ability to attach arbitrary data to the exception. I don't
>>> think adding more special case capability to it is a wise solution in the
>>> long term.
>> This can be said about __FILE__ and __LINE__ which BOOST_THROW_EXCEPTION
>> captures automatically. The reason why it's done is that 1) the cost in
>> terms of time and space is considered negligible and 2) it is potentially
>> critical for debugging.
>> The reason why it Stacktrace would need special handling rather than go
>> through the usual Boost Exception machinery is also the same as why there
>> is special handling (members in boost::exception): to avoid coupling with
>> the rest of the Boost Exception machinery, which is considerably heavier
>> and bigger than boost/exception/exception.hpp.
> The backtrace itself is not a lightweght object

Yes it is. It's basically a list of pointers and we can cap it by default
at, say, 10.

Just to be clear, I'm talking about adding the equivalent of something like
this to the boost::exception class:

void (*stack_trace_[10])();

> so the overhead of the generic Boost.Exception machinery is probably not
> significant. And if that overhead is significant then maybe it could be
> optimized instead. After all, why have it if we don't want to use it.

The cost of using the generic Boost Exception machinery is not limited to
speed and space but also coupling. The boost::throw_exception function
template is not coupled with any Boost libraries, while Boost Exception
itself uses e.g. shared_ptr and a few others. That said, even the runtime
cost of the generic Boost Exception machinery is probably an order of
magnitude bigger than storing 10 pointers.

> Consider that boost::throw_exception must
>> support very very old compilers.
> How old? I mean, it only has to support the oldest compiler Boost
> libraries support.

Yes, which is very old. :) Anyway, the point is that boost::throw_exception
must remain extremely lightweight in terms of dependencies AND it must be
very conservative in terms of using C++ features. Specifically, I am
hinting that std synchronization facilities are off-limits (though to be
fair capturing the stack trace can be commented-out for old compilers.)

> Are you proposing to include <windows.h> in boost/throw_exception.hpp?
>> That's a no-go.
> No. Use approach similar to Boost.WinAPI on Windows (i.e. re-declare
> WinAPI components).
> Making it not header-only module? Also a no-go.
> No.

Requiring to link the Windows kernel? That's a breaking change, too.


Boost list run by bdawes at, gregod at, cpdaniel at, john at