|
Boost : |
Subject: Re: [boost] [Stacktrace] review
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2016-12-15 01:52:58
2016-12-14 22:42 GMT+03:00 Nat Goodspeed <nat_at_[hidden]>:
<...>
> I do have a question about use of a template parameter to constrain the
> number of entries, rather than a runtime parameter. Presumably that's
> necessary to permit certain backend implementations to be
> async-signal-safe? (Whatever the rationale, a note in the documentation
> explaining it would be nice.)
Yes, this is for async-signal-safety + it gives an exception safety +
it removes all the allocator related stuff from the stacktrace. I'll
add a note.
> My objection to that is that apparently, with the present design, if I want
> to write a function that accepts any specialization of basic_stacktrace,
> that must itself be a template function.
Yes, you're right. But in my head - you'll be using the same default
stacktrace with the same template parameter all over the place. So
it's mostly for detecting problems (you'll get link time error while
attempting to link libraries that exchange stacktraces with different
default parameters) and for interoperability with libraries, that may
accept/produce stacktraces that differ from the current.
> If I'm correct about the reason for using a template parameter, would it be
> reasonable to split the class into a non-template base class supporting all
> the methods, with a template subclass that provides the storage? The base
> class could store a (pointer, length) passed by the subclass constructor.
> Without having looked at the implementation, I expect that you wouldn't
> even need virtual-function dispatch: the only indirection would be through
> the data buffer pointer.
There is a detail::backend class, that could be easily transformed to
such class... But I'd rather not, as it seems to be an
overengineering.
> That would even permit a subclass that provides dynamic storage, for
> async-signal-unsafe use.
Could you please give an example, where such class could be useful?
Thank you for the review!
-- Best regards, Antony Polukhin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk