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 10:50:50

2017-03-18 13:40 GMT+03:00 Peter Dimov via Boost <boost_at_[hidden]>:
> Antony Polukhin wrote:
>>
>> <windows.h> is a lesser evil. The huge problem is a COM header with a lot
>> of things in global namespace and a bunch of unportable vendor specific
>> extensions. One pain of death, I'm not going to rewrite all the COM
>> macro-spaghetti code (but I'm open to pull requests). The only good solution
>> to avoid global namespace polution - is not to use the library in header
>> only mode on MSVC.
>
>
> The suggestion is not to rewrite the COM code. It's to not include it unless
> needed.
>
> 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?

>> > 2. There should exist a documented way to construct a stacktrace from an
>> > > array of void const*. This is currently possible via from_dump, but it's >
>> > not guaranteed to work; the format of the dump is technically an >
>> > implementation detail of the library and may change.
>>
>> Where that could be useful?
>
>
> It's useful if one wants to capture the stack trace manually in order to
> avoid a dependency on stacktrace at the capture point.
> boost::throw_exception, for instance, could be made to do so.

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.

But you still can use the boost::stacktrace::frame to decode frames one by one:

void* data[10]; // captured frames
// ...
for (void* f: data) {
    std::cout << boost::stacktrace::frame(f);
}

-- 
Best regards,
Antony Polukhin