The C++ committee accepted what is essentially Boost.System for C++0x. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html for the final proposal. That proposal is now reflected in the working paper for the new standard. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf The committee made some minor last minute changes. Those changes are not yet reflected in Boost.System. The plan is to bring Boost.System into compliance with the standard sometime in the next month or so. There are still a few outstanding issues; missing clear() specs, constexpr needed on a constructor, error_category should be non-copyable, and perhaps one or two others. --Beman
The C++ committee accepted what is essentially Boost.System for C++0x. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html for the final proposal.
That proposal is now reflected in the working paper for the new standard. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf
The committee made some minor last minute changes. Those changes are not yet reflected in Boost.System. The plan is to bring Boost.System into compliance with the standard sometime in the next month or so.
Nice - but I don't know why posix errors are enumerated now. Maybe some posix errors are missing (I'm not sure). Oliver
Oliver.Kowalke@qimonda.com wrote:
The C++ committee accepted what is essentially Boost.System for C++0x. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html for the final proposal.
That proposal is now reflected in the working paper for the new standard. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf
The committee made some minor last minute changes. Those changes are not yet reflected in Boost.System. The plan is to bring Boost.System into compliance with the standard sometime in the next month or so.
Nice - but I don't know why posix errors are enumerated now.
The LWG wanted them to be usable as constants.
Maybe some posix errors are missing (I'm not sure).
Please do an independent check. I have missed something. The POSIX folks suggested adding a couple of new errors POSIX is in process of adding, by the way. Thanks, --Beman
Nice - but I don't know why posix errors are enumerated now.
The LWG wanted them to be usable as constants.
I believe that will cause problems because EAGAIN could have the same value as EWOULDBLOCK (for instance LINUX).
Maybe some posix errors are missing (I'm not sure).
Please do an independent check. I have missed something. The POSIX folks suggested adding a couple of new errors POSIX is in process of adding, by the way.
ESTALE ENXIO EMULTIHOP EDQUOT EAI_ADDRFAMILY EAI_AGAIN EAI_BADFLAGS EAI_FAIL EAI_FAMILY EAI_MEMORY EAI_NODATA EAI_NONAME EAI_SERVICE EAI_SOCKTYPE EAI_SYSTEM Oliver
Oliver.Kowalke@qimonda.com wrote:
Nice - but I don't know why posix errors are enumerated now. The LWG wanted them to be usable as constants.
I believe that will cause problems because EAGAIN could have the same value as EWOULDBLOCK (for instance LINUX).
Can you come up with an actual use case where than would cause problems? (I'm not saying such a use case doesn't exist; merely that I can't think of one offhand.)
Maybe some posix errors are missing (I'm not sure). Please do an independent check. I have missed something. The POSIX folks suggested adding a couple of new errors POSIX is in process of adding, by the way.
ENXIO
That one actually is present in the working paper.
ESTALE EMULTIHOP EDQUOT
Those three are reserved by POSIX, but are not given any definition and so were deliberately omitted. Do you have a counter-argument in favor of including them? If so, how should their enums be defined?
EAI_ADDRFAMILY EAI_AGAIN EAI_BADFLAGS EAI_FAIL EAI_FAMILY EAI_MEMORY EAI_NODATA EAI_NONAME EAI_SERVICE EAI_SOCKTYPE EAI_SYSTEM
None of those are defined by http://www.opengroup.org/onlinepubs/009695399/basedefs/errno.h.html#tag_13_1... which I'm assuming is the gold standard for the POSIX errno.h errors that are the basis for the portable error codes. So even though the errors you mention above are defined elsewhere in the POSIX standard, they seem to me to be in a different error_category. Thanks, --Beman
I believe that will cause problems because EAGAIN could have the same value as EWOULDBLOCK (for instance LINUX).
Can you come up with an actual use case where than would cause problems? (I'm not saying such a use case doesn't exist; merely that I can't think of one offhand.)
If the elements in the error enumeration of the proposal get the corresponding POSIX errno assigned than it EWOULDBLOCK and EAGAIN would cause troubles. On some systems (for instance FreeBSD) EWOULDBLOCK is returned from none-blocking 'accept' if the request would block. On HP/UX it could return EAGAIN.
posix errors are missing (I'm not sure). Please do an independent check. I have missed something. The POSIX folks suggested adding a couple of new errors POSIX is in
Maybe some process of
adding, by the way.
ENXIO
That one actually is present in the working paper.
OK - maybe I overlooked that.
ESTALE EMULTIHOP EDQUOT
Those three are reserved by POSIX, but are not given any definition and so were deliberately omitted. Do you have a counter-argument in favor of including them? If so, how should their enums be defined?
I found it on http://www.die.net/doc/linux/man/man3/errno.3.html.
EAI_ADDRFAMILY EAI_AGAIN EAI_BADFLAGS EAI_FAIL EAI_FAMILY EAI_MEMORY EAI_NODATA EAI_NONAME EAI_SERVICE EAI_SOCKTYPE EAI_SYSTEM
None of those are defined by http://www.opengroup.org/onlinepubs/009695399/basedefs/errno.h .html#tag_13_10 which I'm assuming is the gold standard for the POSIX errno.h errors that are the basis for the portable error codes. So even though the errors you mention above are defined elsewhere in the POSIX standard, they seem to me to be in a different error_category.
The getaddrinfo() function is defined in IEEE Std 1003.1g-2000 (``POSIX.1''), and documented in ``Basic Socket Interface Extensions for IPv6'' (RFC2553). Regards, Oliver
Beman Dawes wrote:
The C++ committee accepted what is essentially Boost.System for C++0x. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html for the final proposal.
Looks nice. With one issue: This document has following wording: virtual string message(error_code::value_type ev) const=0; Returns: A string that describes the error condition denoted by ev. [Note: The intent is to return a locale sensitive string that describes the error corresponding to ev. --end note.] Throws: Nothing. virtual wstring wmessage(error_code::value_type ev) const=0; Returns: A string that describes the error condition denoted by ev. [Note: The intent is to return a locale sensitive string that describes the error corresponding to ev. --end note.] Throws: Nothing. [snip] class error_code { public: // snipped code string message() const; wstring wmessage() const; // snipped code }; locale sensitivity is good, but in this form user is enforced to set/unset global locale each time he wants to use locale sensitive output from error_category like this: std::locale oldLocale = std::locale::global(myLocale); std::cout << err_cat.message(ev); std::locale::global(oldLocale); It is tedious, requires additional work to make it exception safe and thread safe. I propose to change wording to the following: virtual string message(error_code::value_type ev, std::locale loc = std::locale()) const=0; Returns: A string that describes the error condition denoted by ev. [Note: The intent is to return a locale sensitive string that describes the error corresponding to ev. --end note.] Throws: Nothing. virtual wstring wmessage(error_code::value_type ev, std::locale loc = std::locale()) const=0; Returns: A string that describes the error condition denoted by ev. [Note: The intent is to return a locale sensitive string that describes the error corresponding to ev. --end note.] Throws: Nothing. [snip] class error_code { public: // snipped code string message(std::locale loc = std::locale()) const; wstring wmessage(std::locale loc = std::locale()) const; // snipped code }; Then user code would be as simple as: std::cout << err_cat.message(ev, myLocale); global state is not touched here, so no problems with exception and thread safety (I don't take cout into account here) Oleg Abrosimov.
Oleg Abrosimov wrote:
Beman Dawes wrote:
The C++ committee accepted what is essentially Boost.System for C++0x. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2241.html for the final proposal.
Looks nice. With one issue: This document has following wording:
virtual string message(error_code::value_type ev) const=0;
Returns: A string that describes the error condition denoted by ev.
[Note: The intent is to return a locale sensitive string that describes the error corresponding to ev. --end note.]
FWIW, I've already mentioned this to Beman in an off-line conversation. I never got any real feedback on that particular point though. I'm all for the addition of locale overloads of the message related methods. / Johan
participants (4)
-
Beman Dawes -
Johan Nilsson -
Oleg Abrosimov -
Oliver.Kowalke＠qimonda.com