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