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/