Re: [boost] [Boost] [Stacktrace] review

On 15/12/2016 19:52, Antony Polukhin wrote:

2016-12-14 22:42 GMT+03:00 Nat Goodspeed :

...

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.

That makes me nervous, as I imagine that library code will want to transport stack traces around (imagine exception_ptr with stack traces, or future/thread/context/coroutine/fiber integration). But the max required depth can't be known to a library as it depends on the application code that uses the library (and indeed can get quite deep with some of those constructs, eg. when making a future ready fires a continuation that synchronously makes another future ready, and so on). Application-configurable macros could solve some of that but it still feels problematic to me.