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.