Re: [boost] Review Manager needed for stacktrace library

Subject: Re: [boost] Review Manager needed for stacktrace library
From: Nat Goodspeed (nat_at_[hidden])
Date: 2016-10-23 21:09:42

On Fri, Oct 14, 2016 at 2:22 AM, Antony Polukhin <antoshkka_at_[hidden]>
wrote:

Stacktrace is a C++98 library for storing and printing backtraces.
>
> Supports major platforms, does demangling, has API for accessing
> individual frames, supports hashing and comparison operators.
>
> Library: https://github.com/apolukhin/stacktrace
> Docs: http://apolukhin.github.io/stacktrace/index.html
>
> Anyone wishing to become the Review Manager for the library?
>

Maybe? I already have a couple requests.

I do love the idea of a portable facility to capture and/or display stack
traces at any desired point in a running program. Seems way overdue...

It would be even more valuable if line number and source file information
were available. I recognize that you just can't get that under all
circumstances -- but maybe you could document the per-platform
circumstances in which that *could* be retrieved?

If function name, source file and line number were (conditionally)
available, I'd like to be able to retrieve an individual entry that has
accessors returning each of those things -- instead of operator[] returning
only a std::string for function name. Perhaps the source file and line
number would have to be wrapped in boost::optional.

I suggest an object with accessors returning those things, rather than a
struct, so no source code will come to rely on the size or specific data
layout of the returned entry. That should hopefully permit extension, if
there were ever still *more* information available. (In the Glorious
Future, perhaps we could retrieve function parameter values or something.)

Each entry should support streaming to ostream to get reasonable formatting
in the presence or absence of source file and line number information. The
overall stacktrace ostream operator would rely on the entry ostream
operator.

And finally, I'd like both begin()/end() and rbegin()/rend(). size() and
operator[] are great, but they don't support range for.

I hope all the above sounds reasonable...