Hi Peter, Peter Dimov <pdimov@mmltd.net> wrote:

The current intrerface gives priority to system error codes as evidenced by the single argument constructor. I could argue that we need to reverse that and give priority to errno, but another approach would be to just give the two equal standing with a from_sysno enum.

I would prefer that they are given equal weight, but as I've said elsewhere I also believe there's a need for other error categories.

It isn't clear why there is no error_code::message() const. Probably to not introduce a dependency on std::string and to avoid a copy. In my opinion, if you have to convert error codes to strings in an inner loop where the copy might be of any significance, you have already lost. :-) So I'd prefer the user-friendlier approach of

std::string error_code::message() const; std::wstring error_code::wmessage() const;

as people generally prefer members.

IMHO the error_code class should have fewer member functions, not more, and it should look more like a class that emulates a builtin type. However this line of thinking is probably driven by how I see this class being used wrt asio. Here's another thought: since POSIX strerror is defined to return a locale-dependent string, perhaps a C++ equivalent ought to use std::locale? (However, in practice this needs to be implemented on top of available system APIs, and I don't know if it's possible to implement std::locale-based functions in terms of setlocale().)

The introduction of operator== is also of questionable utility as it also forces us to prefer one of the two codes over the other.

If the constructors give equal weight to error types, then this would not be a problem. I think operator== and != are necessary because I would like to be able to define global error objects for the "well known" errors that can be returned by socket operations. E.g.: namespace boost { namespace asio { namespace error { extern const error_code eof; extern const error_code network_reset; extern const error_code operation_aborted; ... }}} These values would just be compared against the result of operations, as in: void handle_read(error_code ec) { if (ec == boost::asio::error::operation_aborted) ... } Whether the underlying error is an errno or a sysno isn't relevant to these use cases. Cheers, Chris

Peter Dimov <pdimov@mmltd.net> wrote:

Christopher Kohlhoff wrote:

...

IMHO the error_code class should have fewer member functions, not more, and it should look more like a class that emulates a builtin type. However this line of thinking is probably driven by how I see this class being used wrt asio.

As long as there is at least one member, it's no longer a built-in-like. :-)

Elsewhere I suggested that errno_value() and sysno_value() getters could be replaced by overloads of the free functions to_errno and to_sysno. If the setters are also removed as suggested in this thread, then that leaves a grand total of 0 named member functions :)

I think that messages are fine as-is. Their primary audience is people who don't care about languages and locales (the same audience that finds what() useful). Programmers who do care will create their own mapping tables based on errno (or sysno, if they don't need portability for the error message module).

I'm not particularly fussed, but if we implement in terms of strerror (or strerror_r) on POSIX platforms then we are already getting locale support, but it's the C locale which determines the error message.

An operator== that compares both sysno_vaue() and errno_value() would allow the above to work reliably, though... as long as there is a single sysno in the OS, as you pointed out. :-)

Yes, this does makes me think that it might be better if an error_code only had one true value, and that value is represented by whatever category and error number it is created with. It would only compare as equal to another error_code that was created with exactly the same category and error number. Conversion between errors in different categories should then be explicit (using to_errno or to_sysno, say). I don't know what implications this would have on the use of error_code in the filesystem library, however. Cheers, Chris

Peter Dimov <pdimov@mmltd.net> wrote:

Christopher Kohlhoff wrote:

...

Yes, this does makes me think that it might be better if an error_code only had one true value, and that value is represented by whatever category and error number it is created with. It would only compare as equal to another error_code that was created with exactly the same category and error number. Conversion between errors in different categories should then be explicit (using to_errno or to_sysno, say).

It does have the disadvantage that you would be able to have

e1.sysno == e2.sysno && e1.errno == e2.errno && e1 != e2

though. :-)

I think this is a good argument for naming the accessor functions (whether they are member functions or not) to clearly indicate that they perform lossy conversions. To me, the names sysno_value() and errno_value() don't convey this -- they sound like they are simple accessors for data members (until one consults the documentation). And as Peter demonstrates above, one might reasonably expect that comparing all exposed data members would give the same result as operator==. But, if the names were something like to_sysno/to_errno or as_sysno/as_errno, the above expression would become: e1.to_sysno() == e2.to_sysno() && e1.to_errno() == e2.to_errno() && e1 != e2 and I no longer think it looks surprising. Cheers, Chris