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: 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.