On Tue, Jan 16, 2018 at 7:50 AM, Niall Douglas via Boost <
boost@lists.boost.org> wrote:
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