Re: [boost] [system] Was: Re: [asio] Breaking changes committed to cvs HEAD
Hi Johan, Johan Nilsson <r.johan.nilsson@gmail.com> wrote: [...]
2) I've implemented similar code previously, but only designed for portability with linux and Win32. What I very often use, is something corresponding to retrieving errno or calling GetLastError (on Win32).
With the current design, it is harder to implement library code throwing system_errors (retrieving error codes) as you'll need to get the corresponding error code in a platform-specific way. Or did I miss something?
I think the intention is that platform specific library implementations will initialise the error_code in a platform-specific way. At least, this is what asio does.
4) I'm wondering about best practices for how to use the error_code class portably while maintaining as much of the (native) information as possible. Ideally, it should be possible to check for specific error codes portably, while having the native descriptions(messages) available for as much details as possible. Using native_ecat and compare using to_errno?
Asio and its TR2 proposal provide a set of global constants of type error_code that can be used for portably checking for well known error codes. See sections 5.2 and 5.3.2.6 in N2054 for more detail: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2054.pdf Cheers, Chris
Christopher Kohlhoff wrote:
Hi Johan,
Johan Nilsson <r.johan.nilsson@gmail.com> wrote: [...]
2) I've implemented similar code previously, but only designed for portability with linux and Win32. What I very often use, is something corresponding to retrieving errno or calling GetLastError (on Win32).
With the current design, it is harder to implement library code throwing system_errors (retrieving error codes) as you'll need to get the corresponding error code in a platform-specific way. Or did I miss something?
I think the intention is that platform specific library implementations will initialise the error_code in a platform-specific way. At least, this is what asio does.
Boost.Asio as such isn't platform-specific. Wouldn't you (as a library implementor) prefer to do as much as possible in a portable way?
4) I'm wondering about best practices for how to use the error_code class portably while maintaining as much of the (native) information as possible. Ideally, it should be possible to check for specific error codes portably, while having the native descriptions(messages) available for as much details as possible. Using native_ecat and compare using to_errno?
Asio and its TR2 proposal provide a set of global constants of type error_code that can be used for portably checking for well known error codes. See sections 5.2 and 5.3.2.6 in N2054 for more detail:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2054.pdf
I was looking for something like that, yes. Shouldn't that part be included (but more exhaustively) in the Diagnostics proposal? Also, I would personally prefer names that are less likely to clash with others if the containing namespace is brought into scope by using namespace <ns containing error codes>; error_access_denied, error_address_family_not_supported etc. Regards, Johan
participants (2)
-
Christopher Kohlhoff -
Johan Nilsson