llvm dev - Mar 2014 - [LLVMdev] Users of llvm::error_code all inherit from _do_message

There are several libraries in LLVM that create their own `error_code`
categories, so that they can return errors in a consistent way and with
convenient messages.

To do this, these libraries create an error category type that inherits
from `_do_message` in system_error.h. There are a number of ways that
this is wrong:

1. From the name, it's quite clear that _do_message is an implementation
   detail.

2. The only function defined in _do_message is specifically intended for
   system errors that report via errno, which is not what the custom
   categories are doing.

As far as I can tell, the custom categories are only inheriting from
_do_message is apparently to get around the fact that error_category's
constructor is private, and that _do_message is a friend class of
error_category.

If we want to continue using error_code the way we currently are, I
think the right thing to do here is to make error_category's constructor
protected and stop inheriting from _do_message.  Would anyone object to
that?

On Fri, Mar 14, 2014 at 2:52 PM, Justin Bogner <mail at justinbogner.com>
wrote:
> There are several libraries in LLVM that create their own `error_code`
> categories, so that they can return errors in a consistent way and with
> convenient messages.
>
> To do this, these libraries create an error category type that inherits
> from `_do_message` in system_error.h. There are a number of ways that
> this is wrong:
>
> 1. From the name, it's quite clear that _do_message is an
implementation
>    detail.
>
> 2. The only function defined in _do_message is specifically intended for
>    system errors that report via errno, which is not what the custom
>    categories are doing.
>
> As far as I can tell, the custom categories are only inheriting from
> _do_message is apparently to get around the fact that error_category's
> constructor is private, and that _do_message is a friend class of
> error_category.
>
> If we want to continue using error_code the way we currently are, I
> think the right thing to do here is to make error_category's
constructor
> protected and stop inheriting from _do_message.  Would anyone object to
> that?
Hmm, I'm not sure why error_category's constructor is private. It's
not what the spec says.

This change is fine, but we should eventually move over to
std::{error_code,error_category}. We'll need to investigate first how
to properly handle windows_error though, I believe that on MSVC the
system_category properly maps to the Windows error codes. Not sure how
MinGW handles it though.

- Michael Spencer

Michael Spencer <bigcheesegs at gmail.com> writes:
>> If we want to continue using error_code the way we currently are, I
>> think the right thing to do here is to make error_category's
constructor
>> protected and stop inheriting from _do_message.  Would anyone object to
>> that?
>
> Hmm, I'm not sure why error_category's constructor is private.
It's
> not what the spec says.
I've changed it to public in r203998 to match the spec. I updated the
users as well.
> This change is fine, but we should eventually move over to
> std::{error_code,error_category}. We'll need to investigate first how
> to properly handle windows_error though, I believe that on MSVC the
> system_category properly maps to the Windows error codes. Not sure how
> MinGW handles it though.
I don't have MSVC or mingw to test with, so I'm not comfortable making
the change, but now that we've switched to C++11 we should certainly
look into switching to std:: for this.