Boost logo

Boost :

Subject: Re: [boost] [Stacktrace] Second review begins today 17th Mar ends 26th Mar
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2017-03-18 20:21:10

On 2017-03-18 02:09, Niall Douglas via Boost wrote:
> I am pleased to announce the second review of the proposed
> Boost.Stacktrace library running from today until Sunday 26th.

Started reading the docs. Looks very satisfying and I see wanting/using
it extensively. I certainly vote for acceptance. My personal view is
that the lib is very useful/needed. So, the sooner it gets wider
deployment the sooner issues and niggles are to be addressed.

The default deployment seems straightforward with the option for
customization for adventurous. I like that. I was irked by
boost::stacktrace::stacktrace() invocation though. Not a huge drama but
boost::stacktrace() certainly looks far more natural to me. Started
looking what there was in the boost::stacktrace namespace. It appears
quite a few things could be be better encapsulated in the relevant
classes. For ex., basic_stacktrace and frame comparison operators are
all outside the respective classes.

namespace boost {
   namespace stacktrace {
     class frame;

     bool operator<(const frame & lhs, const frame & rhs);
     bool operator>(const frame & lhs, const frame & rhs);

However, the frame class has no implicit constructor to take advantage
of such placement. So, those operators might go (and belong IMO) inside
the frame class. Same IMO goes for basic_stacktrace. Functions in the
boost::stacktrace namespace might become static functions inside
boost::stacktrace class. Supporting functionality might go into some
boost::stacktrace_detail namespace. That'd allow boost::stacktrace to be
actually a class and consequently visible to the users as simply
boost::stacktrace(). That'd be nice.

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