Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-21 14:35:58

On 21/05/2017 14:39, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
>> > The vast majority of your user base may change if your library is >
>> accepted. It almost certainly will.
>>
>> I would still expect a vast majority to not want a Boost dependency.
> 
> The vast majority get their Boost libraries through some form of a Boost
> release.

The vast majority do something like:

apt-get install libboost-filesystem-dev

So they ask for the library they need, and get lots of other stuff too
(filesystem is actually pretty good, only four or five dependent boost
libraries, others basically drag in libboost-all-dev)

> For them, the phrase "a Boost dependency" makes no sense at
> all. You could legitimately talk about depending (or not depending,
> which is preferable) on a specific Boost module, but not depending on
> Boost in general has no meaning when you're part of Boost in general.

All the evidence to date suggests that people far prefer Boost libraries
without the monolithic Boost dependency, and especially without a
Boost.Build dependency.

Standalone ASIO is much more popular than Boost.ASIO

Standalone Hana I am told is much more popular than Boost.Hana, but
maybe Louis will confirm or deny.

I expect the same to be the case with standalone Outcome. An
overwhelming majority of developers outside boost-dev want Boost quality
libraries without the Boost dependency. This topic comes up **very**
frequently on Reddit and Stackoverflow. People have tried to explain
this here on boost-dev, but it has not been well received. I don't want
to rehash those arguments during this review. I've said all I intend to
on that topic.

I will reiterate that if reviewers want a boost-flavoured Outcome which
doesn't default to the C++ 14 STL, that's no problem to achieve.

>> People want C++ 14 libraries to use the C++ 14 STL, not Boost,
> 
> Not a problem at all here, but not what we're talking about. You've
> eliminated a dependency on Boost, but substituted a dependency on
> something called Boost Lite. For people who acquire your library as part
> of Boost, this is not an asset, it's a liability. (For those who don't,
> it's vice versa.)

It is not a dependency if it comes bundled internally. Which it does. No
external downloads nor installs needed unless you are using the git repo
(and even then, fetchRecurseSubmodules is set to true, so a simple git
submodule update should work if your git is new enough).

>> I should mention that boost-lite derives its macros from the C++ 17
>> feature macros, which all recent editions of major compilers support
>> even in C++ 14 mode.
> 
> Does MSVC support SD-6 macros? I thought that it didn't.

I believe they appeared in an update of VS2015, and are present in
VS2017. __has_include also appeared and mostly works, though it is buggy.

>> The tutorial covers the need in real world code to attach some sort of
>> payload to error codes. Outcome provides error_code_extended with a
>> reasonable set of the most common likely payloads.
> 
> 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.

> Speaking of which, can you please give me a few examples of what goes
> into the two codes (code1 and code2)?

Totally up to the end user.

You could store a void * across both 32 bit codes.

You could store a thread id in one and the bottom 32 bits of this in the
other.

Lots of options. I chose 64 bits as it's the minimum which is versatile.

In my own code, I define a local make_errored_result<>() function which
wraps the Outcome one, but adds in custom code1 and code2 where appropriate.

>> I would add that if you do not use any of the payload,
>> error_code_extended is identical to an error_code, no overhead.
> 
> Apart from the additional size_t.

I benchmarked the effects of that additional 8 bytes. No statistically
measurable difference.

> But it occurs to me that you can hide
> that on x64 if (a) you make it 32 bit - should be enough for a ring
> buffer - and (b) you do not derive from std::error_code but instead
> store the members directly in the correct order.
> 
>    int32_t cookie_;
>    int value_;
>    std::error_category const * cat_;

The ability to implicit type slice an error_code_extended to an
error_code may well be felt to be an issue by reviewers. If explicit
conversion were felt desirable despite creating boilerplate, then
definitely yes you'd optimise storage. But as I mentioned, I found no
statistical difference in performance with the additional 8 bytes. After
all, one is not creating large arrays of error_code_extended.

>> I'll leave it to reviewers to decide on whether defaulting to the C++
>> 14 STL std::error_code or to boost::error_code is the most appropriate.
> 
> I'm not sure you understand me here... I'm saying that there's no need
> to default to boost::error_code or even keep the stl11:: way of choosing
> between the two.

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/