Subject: Re: [boost] [outcome] some problems compiling
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-25 14:42:55
>> The code in question is in a sub-sub-library which is itself completely
>> standalone and reusable. It is Windows only because it implements a
>> common POSIX API for Windows, so such attributes won't be useful. And
>> that code would only ever get used if someone didn't configure a better
>> stack backtrace printer.
> Speaking of, now that StackTrace has been accepted into Boost, are you
> considering migrating that code to use it instead?
As I have stated many times now, the stacktrace captured is 100%
standard format and can be fed to any third party stack trace printer,
including Boost.Stacktrace. The very minimal support provided out of the
box is there for the majority of users who don't care about maximum
information stack trace prints.
> Somewhat related, the docs for error_code_extended::backtrace() specify
> that the returned value must be freed. Is that referring only to the
> array itself or must the individual char* within the returned char** be
> individually freed as well?
Yes, the wording is confusing now I look at it. It's fixed in develop
branch. Thanks for the spot.
> 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 **.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk