pt., 4 sty 2019 o 20:55 Emil Dotchevski via Boost
On Fri, Jan 4, 2019 at 6:07 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
śr., 19 gru 2018 o 03:00 Emil Dotchevski via Boost < boost@lists.boost.org> napisał(a):
LEAF is a small C++11 error handling library (the acronym stands for Low-latency Error Augmentation Framework).
Features:
- Header-only, NO dependencies. - No dynamic memory allocations. - Associate objects of arbitrary types with any failure — when it is initially reported or at a later time. - Compatible with std::error_code, errno and any other error handling API. - Use with or without exception handling. - Support for multi-thread programming.
Official documentation: https://zajo.github.io/leaf.
LEAF is designed for use in low-latency environments without exception handling, but it also works with exception handling; in that case it is a better, more optimal replacement for Boost Exception. This link can be helpful for refactoring existing Boost Exception code: https://zajo.github.io/leaf/#boost_exception.
Hi Emil, Thank you for sharing the library. I only had a look at the documentation (which is really high standard) to try to determine the difference between LEAF and Boost.Outcome. It is my understanding that the main difference is that LEAF allows heap-free type erasure of error-related data at the expense of exploiting thread-local storage. Is this a fair summary?
LEAF does not store the error objects in thread-local storage, they are moved from error-reporting functions directly into a std::tuple stored locally in the error-handling function. This is entirely static and type-safe.
I know there are people who want to focus on LEAF using thread-local storage, but 1) this is limited to static pointers (no dynamic initialization or destruction of TLS objects) and 2) it doesn't do justice to the design. I've included in the documentation what I believe is a fair analysis of the different design choices made by LEAF and Boost Outcome: https://zajo.github.io/leaf/#_comparison_to_boost_outcome.
Thanks for the clarification. The reason for the interest in TLS usage is that accessing any globals (TLS being a global in this sense), including ints and pointers, makes functions not refrentially transparent and inhibits optimizations such as common subexpression elimination. I guess this concern will be addressed when some benchmarking is performed. I acknowledge that this is not the only difference between the two libraries. I guess it is just my bias towards performance that makes me overlook other aspects. Regards, &rzej;