On Fri, Dec 16, 2016 at 12:24 PM, Andrey Semashev wrote: On 12/16/16 22:32, Emil Dotchevski wrote: On Fri, Dec 16, 2016 at 1:20 AM, Andrey Semashev <
andrey.semashev@gmail.com>
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 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