On Fri, Dec 16, 2016 at 12:24 PM, Andrey Semashev <andrey.semashev@gmail.com
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 <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