Boost logo

Boost :

Subject: Re: [boost] [Stacktrace] Review Manager report
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-01-02 11:40:31

On 01/02/17 19:14, Niall Douglas wrote:
> From the reviews, I think there is consensus that the minimum viable
> product is achieved in Stacktrace though many mentioned that
> improvements are needed to the documentation and most of the negative
> feedback was on features not in the minimum viable product described
> above. I therefore recommend the ACCEPTANCE of proposed Boost.Stacktrace
> into Boost with the following conditions:
> 1. That the documentation more clearly set out what Stacktrace does and
> especially does not do, and that the default facilities provided are
> those of the Minimum Viable Product described above i.e. no source file
> nor line number discovery, no external dependencies on libraries not
> always provided on the target platform, no invocation of child
> processes, no async safety during stacktrace parsing. Stacktrace ought
> to be pared back to the minimum viable product featureset with no
> external dependencies at all.
> 2. That suitable predefined macros opt in to additional functionality
> such as serialisation of offset translated backtraces, retrieval of
> source code path and line number etc. Enabling these may introduce
> dependencies on third party libraries not always present on a system
> such as libunwind, or on third party helper utilities such as addr2line.
> I would recommend that the APIs the use of which are dependent on such
> third party items are entirely compiled out of Stacktrace when the macro
> enabling them is not defined.
> 3. That the documentation describe ONLY the default minimum viable
> product functionality in its tutorial and quick start. All extra
> functionality enabled by macros is to be relocated into a separate
> documentation section away from the main documentation e.g.
> "Advanced/optional features".
> 4. That APIs made available only when a given macro has turned them on
> are documented as such in the API reference docs.

Thanks Niall for managing the review and congrats to Antony.

I have to say though that I really don't think that a macro-based
solution is the right way to go when a policy based pure C++ solution is
possible. Config macros tend to result in compatibility issues when
defined differently in different areas of the application, and
stacktraces have the potential of travelling long distances across the
application code if attached to exceptions.

Boost list run by bdawes at, gregod at, cpdaniel at, john at