Re: [boost] Review Manager needed for stacktrace library

On Mon, Oct 24, 2016 at 2:05 PM, Antony Polukhin wrote:

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

...

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

...

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.

Hence the desire to be able to retrieve individual components of a stacktrace entry. A consumer could extract just the parts s/he cares about. I do want operator<<(std::ostream&, const stacktrace_entry&) to provide default formatting, but being able to extract individual fields (without parsing your output!) would allow a consumer to format in whatever way s/he needs.

...

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.

Okay, that would be a reason to avoid std::optional. You could define a distinguished value to mean "not available."

...

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.

Well, to be honest, I doubt I care much about the instruction address per se -- only the line number in the source file that it indicates. But the wrapper layer for each backend could "do the right thing" in extracting the instruction in whatever common form you decide, could it not?

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?

As I said, I want to be able to extract particular pieces of information without having to maintain backend-specific parsing of the string you emit. Ultimately, of course, it's all for human consumption, but you can't know the format I will consider ideal. It's great to be able to extract a single stacktrace entry, and it's good to have a "good enough" default formatting, but I'm just telling you what I would like even better. ;-)