Re: [boost] [Stacktrace] Second review begins today 17th Mar ends 26th Mar

Subject: Re: [boost] [Stacktrace] Second review begins today 17th Mar ends 26th Mar
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2017-03-18 14:17:21

2017-03-18 14:11 GMT+03:00 Peter Dimov via Boost <boost_at_[hidden]>:
> Antony Polukhin via Boost wrote:
>>
>> > template <class E>
>> > void throw_with_trace(const E& e) {
>> >    throw boost::enable_error_info(e)
>> >        << traced(boost::stacktrace::stacktrace());
>> > }
>> >
>> > Here no COM or <windows.h> code is needed, but there's no way to avoid >
>> > their inclusion.
>>
>> How it could be done?
>
>
> By splitting stacktrace.hpp and frame.hpp into two headers, one with the
> parts that do not need <windows.h>, the other with the rest. The code above
> would then be able to only include the first header. Picking some names at
> random,
>
> stacktrace.hpp
>    stacktrace_def.hpp
>    stacktrace_impl.hpp
>
> frame.hpp
>    frame_def.hpp
>    frame_impl.hpp
>
> stacktrace_def.hpp
>    frame_def.hpp
>
> stacktrace_impl.hpp
>    frame_impl.hpp
>
> although currently stacktrace has no impl parts, so it could be simplified
> to
>
> stacktrace.hpp
>    stacktrace_def.hpp
>    frame_impl.hpp
>
> stacktrace_def.hpp
>    frame_def.hpp
>
> frame.hpp
>    frame_def.hpp
>    frame_impl.hpp

windows.h is a minor problem of a single platform. It already has an
ultimate fix - use the non header-only version of the library. Most of
the Boost users do not care about windows.h inclusion, those who care
can link with the library. I'm not going to uglify the library by
doubling/tripling the headers count and I'm definitely not going to
make it's understanding harder just to satisfy the minority of users
that use win platform + use MSVC + do not like windows.h header + do
not wish to link + somehow wish to use only the non functional COM
part of the library (that contains only a single CaptureStackBackTrace
call).

>> std::thread has no constructor from std::thread::native_handle_t and I'd
>> like to follow that pattern. If you've done something using
>
> platform specific methods - you're on your own.
>
> This makes no sense to me, especially since frame is constructible from void
> const*. stacktrace is just an array of frames.

It also increases the risk that people will capture the frames in a wrong way:
* It's very easy to do it wrong on Windows, because it has multiple
APIs for doing so and only one of them is safe. Moreover, the bad APIs
have more examples and docs, so it's easier to choose wrongly.
* It's terribly easy to do it wrong on POSIX, because it has
documentation only on a bad API.

-- 
Best regards,
Antony Polukhin