Re: [boost] [Stacktrace] review

Subject: Re: [boost] [Stacktrace] review
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-12-15 17:50:02

On 15/12/2016 19:52, Antony Polukhin wrote:
> 2016-12-14 22:42 GMT+03:00 Nat Goodspeed <nat_at_[hidden]>:
>> 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.