Re: [boost] Reforming Boost.System and <system_error> round 2

Subject: Re: [boost] Reforming Boost.System and <system_error> round 2
From: charleyb123 . (charleyb123_at_[hidden])
Date: 2018-01-16 15:08:33

On Tue, Jan 16, 2018 at 7:50 AM, Niall Douglas via Boost <
boost_at_[hidden]> wrote:
<snip, discuss overhead of 'std::error_code' checks>
>
> You might be interested to learn that in a real world code base I
> tested, padding error_code's size to 64 bytes produced no statistically
> observable slowdown on Intel Ivy Bridge. As soon as it tipped over 64
> bytes though, it became very noticeable, about 5%. That was for
> error_code_extended in Outcome v1, I wanted to see how much payload I
> could cram in there.
>
> So when you say error_code comes with baggage over C error codes, I'll
> claim that you could in fact add lots more baggage still and probably
> see little effect.
>

This is interesting:  There's a long-recognized need for instance-specific
error parameter-values (e.g., a "key-value-map" for parameters, such as to
include the `file-name` that we we failed to open).  This seems to be the
"number-one" reason to create user-specific wrappers around
`std::error_code`.

So, adding an 'std::unique_ptr<>` member to `std::error_code` would allow
that; and could also solve the memory-transport issue to remove
`std::string` from the `std::error_code` interface.

Recall that currently (on *all* platforms that I'm aware of),
`sizeof(std::error_code) == sizeof(int)+sizeof(void*)`.

...so, this idea would add `sizeof(unique_ptr<>)` to `std::error_code`.

--charley