On 26/05/2017 02:42, Niall Douglas wrote:
Why doesn't this just return
std::vectorstd::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::vectorstd::string, perhaps returning a std::unique_ptr 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::vectorstd::string return value. It avoids both
issues.
