Subject: Re: [boost] Requesting formal review for (Boost) LEAF
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-01-08 09:46:01
pt., 4 sty 2019 o 20:55 Emil Dotchevski via Boost <boost_at_[hidden]>
> 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 <
> > 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
> > > 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
> > LEAF and Boost.Outcome. It is my understanding that the main difference
> > 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
> 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:
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk