Boost logo

Boost :

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-21 13:39:36

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. 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.

> 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

> Including Outcome does not include <windows.h>, except on winclang

Yes, I happened to have my toolset set to Clang.

> 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.

> 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.

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

> 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. 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_;

> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at