Re: [boost] Requesting formal review for (Boost) LEAF

Subject: Re: [boost] Requesting formal review for (Boost) LEAF
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2019-01-04 19:54:30

On Fri, Jan 4, 2019 at 6:07 AM Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:

> śr., 19 gru 2018 o 03:00 Emil Dotchevski via Boost <boost_at_[hidden]>
> 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.