|
Boost : |
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2020-05-04 00:40:52
Thanks for the interest.
On Sun, May 3, 2020 at 4:15 PM Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:
> It can service the environments where TLS is affordable.
You're assuming that the use of TLS pointers to error objects in LEAF,
moving error objects directly to the scope where they are needed, bypassing
return values and stack frames, is less efficient than transporting them in
return values. Depending on your platform and your error object types, it
could go either way.
Separately, LEAF can transport any number of error objects of arbitrary
types without dynamic allocations. If you need to do this with a
conventional result<T> implementation, you'll be allocating memory. That
may be as much of a showstopper as unavailability of TLS could be for LEAF.
For a similar reason, I find the comparison with Boost.Outcome, at the end
> of documentation, unfair. If the goal of this comparison is to help people
> decide which library is best suited for them, LEAF or Outcome, the usage or
> non-usage of TLS is an important factor.
>
It's important but not in terms of efficiency, only in terms of
availability and suitability. LEAF is not suitable for coroutines or GPUs
(though GPU code doesn't need much in terms of error handling anyway).
LEAF works well with async code based on threads, see:
https://github.com/zajo/leaf/blob/master/examples/capture_in_result.cpp?ts=4
(without
exceptions)
https://github.com/zajo/leaf/blob/master/examples/capture_in_exception.cpp?ts=4
(using
exceptions)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk