Re: [boost] [Stacktrace] review

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.

Emil