Re: [boost] Review Manager needed for stacktrace library

2016-10-24 4:09 GMT+03:00 Nat Goodspeed :

On Fri, Oct 14, 2016 at 2:22 AM, Antony Polukhin wrote: <...>

...

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.

Thank you! But Niall already agreed to be the Review Manager: http://www.boost.org/community/review_schedule.html

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?

The idea is good and I'm definitely going to experiment with that for Windows platform and for the Linux platforms soon. But I'm afraid that it may lead to bigger backtraces that do not fit onto screen and are harder to read.

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'm writing stacktrace library as a prototype for further adoption into the C++ Standard (I've got big ambitions and groundless optimism). Additional dependency to std::optional could make the adoption harder.

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.

I've tried to walk that way. Unfortunately outputs differ a lot depending on the backtrace backend. For example instruction address may be reprsented as: * absolute address for currently loaded executable * offset from the stack frame * offset from the section in the binary It's hard to unify even those. More problems will arise with source files and line numbers. May be you'd like a different solution? What for are you willing to have such precise control?

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

Sounds right. I'll add iterators and begin,end,rbegin,rend. Great thanks! -- Best regards, Antony Polukhin