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 versa.)
Including Outcome does not include
, 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.