pon., 4 maj 2020 o 02:41 Emil Dotchevski via Boost
Thanks for the interest.
On Sun, May 3, 2020 at 4:15 PM Andrzej Krzemienski via Boost < boost@lists.boost.org> 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.
I am sorry. It was a bad choice of words on my side. I did not mean to imply that the usage of TLS would make the library go slower compared to alternatives. What I was trying to say is that on some platforms LEAF would not compile because of the missing TLS support, and that I would only discover it after having invested a significant amount of time, because the documentation does not declare it up front. These are the guidelines that I learned from Robert Ramey's talk on documenting a library (https://www.youtube.com/watch?v=ACeNgqBKL7E). As a potential user I need to learn in no more than 5 minutes: what the library does, how I will use it (LEAF documentation does it perfectly), and what are the requirements. For the last point I would expect to see: "your platform needs to support TLS, and your program cannot use coroutines in asynchronous manner." IOW: high-level design trade-offs should be documented up front.
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.
I acknowledge this. And I think this part is nicely outlined in the documentation. My critique was not about the trade-offs that the library does. It was about not documenting it clearly. As a side note, the choice of providing efficient stack storage for arbitrary number and kind of error objects does not necessarily require the usage of STL. An alternative described in https://www.research.ed.ac.uk/portal/files/78829292/low_cost_deterministic_C... creates a similar stack storage, but instead passes a pointer to it to every function that needs to report a failure using this mechanism. But the authors are implementing it as a compiler extension, and this choice to pass the pointer to the storage to all function may not be suitable for a library implementation. So the trade-off here is: TLS in order to preserve the normal set and type of function inputs.
of documentation, unfair. If the goal of this comparison is to help
For a similar reason, I find the comparison with Boost.Outcome, at the end 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).
Regarding platforms that do not support TLS, I will learn about it the hard way when I try to compile the library, which is enough to avoid any bugs. However, not being suitable for coroutines is more serious, because the library will compile and maybe even execute as expected in simple test cases. And it may give false impression that this just works. I would recommend putting a visible note in the documentation saying that the library is using TLS and therefore is not suitable for programs that use coroutines for asynchronous calls.
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?t... (using exceptions)
Acknowledged. Regards, &rzej;
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost