Re: [boost] [outcome] some problems compiling

Subject: Re: [boost] [outcome] some problems compiling
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-25 23:57:36

On 26/05/2017 02:42, Niall Douglas wrote:
>> Why doesn't this just return
>> std::vector<std::string> or some kind of smart pointer for avoidance of
>> doubt and exception-safety?  It feels like this is allowing
>> implementation details to escape unsafely.
> 
> The implementation literally returns what backtrace_symbols() returns,
> which is a malloced char **.

I assumed that, hence my comment about a leaking implementation detail. 
That's a reasonable return value for a C library like backtrace_symbols; 
it's bad style for a C++ library.

If you don't want the expense of copying the strings individually to a 
std::vector<std::string>, perhaps returning a std::unique_ptr<char**, 
c_free> would be a reasonable compromise for that specific issue, 
although that still masks the array-ness so it's not ideal.

The other problem with this API as it stands is that it provides no way 
to convey the actual number of frame strings returned. 
backtrace_symbols() in the underlying library makes no guarantee to 
null-terminate the array, as far as I can tell.  raw_backtrace(), or 
backtrace() in the underlying library, does give you the number of 
frames filled but this information is not available to the caller of 
error_code_extended::backtrace() unless they call raw_backtrace() 
separately, which seems pointless.

Since symbolising the trace is inherently an expensive operation anyway 
I don't think it's worth worrying about avoiding the copy, which is why 
I suggested the std::vector<std::string> return value.  It avoids both 
issues.