Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-05-21 18:47:59
On Sun, May 21, 2017 at 7:35 AM, Niall Douglas via Boost <
> Standalone ASIO is much more popular than Boost.ASIO
What do you mean by that? You can't possibly mean that standalone
Boost.ASIO is more distributed by Boost -- Boost releases are everywhere!
> > Yes, the need to attach more information to error codes is genuine. For
> > exceptions Boost.Exception lets us do that non-intrusively, but for
> > error codes we do not have a similar framework.
> Boost.Exception allocates memory to do that. Allocation of memory is not
> possible anywhere in Outcome, it ruins the point of using it for low
> latency C++ which is a big user base.
Control may have exited low latency contexts. High level contexts may have
information relevant to an error detected and reported by low level code.
There is no harm in providing the _ability_ to carry it.
Secondly, the problem of memory allocation can be dealt with using
alocators and shared_ptr.
Generally, if a low level context has data that might be needed to handle
the error, there should be a mechanism to report it, doubly so because it
is tricky. By not dealing with this problem you're pushing that
responsibility to the users who may need it.
Retaining standalone usability of Outcome is a high priority for me. A
> lot of folk from SG14 are interested in using Outcome, and I intend to
> submit Outcome into SG14's collection of low latency suitable libraries.
Could it be that making it part of Boost is low priority then? Or at least
The way I see it, if you want to be part of Boost, you should be a "good"
member of Boost, and this does mean to *by default* include config, assert
with BOOST_ASSERT, throw using BOOST_THROW_EXCEPTION, and a few other
things. You can then support others users, for example let them #define
OUTCOME_STANDALONE and you #ifdef out all Boost dependencies.