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: Peter Dimov (lists_at_[hidden])
Date: 2017-03-20 11:34:20

Niall Douglas wrote:

> So, you're looking for the stacktrace and frame classes to not provide 
> implementations of those member functions which rely on windows.h?
>
> I assume you then want an additional header file e.g. 
> "stacktrace_extra.hpp" which provides implementations for those?

Something like that.

There are three possible ways to do it, and I haven't yet settled on one, or 
I'd have issued a pull request, as Antony asked.

1.

#include "stacktrace.hpp" // as today, includes everything
#include "stacktrace_def.hpp" // stacktrace without op<< or to_string

In header-only libraries that don't use op<< or to_string, include the 
second header instead of the first.

2.

#include "stackrace/stacktrace.hpp" // without op<< or to_string
#include "stacktrace/output.hpp" // op<<, to_string

Straightforward split into two headers, the difference is only that you need 
to explicitly include output.hpp for op<<.

3.

#include "stacktrace.hpp" // declarations of everything, no definitions, no 
windows.h/COM

#define BOOST_STACKTRACE_IMPLEMENTATION
#include "stacktrace.hpp" // definitions, using windows.h, COM

The usual way of packaging a non-header-only library in headers. The user 
defines BOOST_STACKTRACE_IMPLEMENTATION in one and only one .cpp file. No 
BOOST_STACKTRACE_LINK macro is necessary - if you link with the library, you 
just don't need to do the aforementioned.

At the moment, I tend towards the third alternative, because it's a known 
practice and replaces the already existing BOOST_STRACKTRACE_LINK mechanism, 
so it doesn't introduce additional configuration complexity.

Ideally, in (3), if you don't use op<< or to_string (or frame::name and so 
on), you won't need to include the implementation. So if you use a 
header-only library that includes stack traces in its exceptions, but you 
ignore these stack traces because you know nothing about the stacktrace 
library and don't use it, you won't have to pay the price if 
linking/including the implementation.

In implementation terms, this_thread_frames::collect will have to be 
header-only so that the stacktrace constructors do not trigger link errors, 
the rest not.