Hi Johan, Johan Nilsson <r.johan.nilsson@gmail.com> wrote:

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?

The interface isn't platform specific, but the implementation at the lowest level is very much so. And an error_code parameter is used in the functions at these lowest levels. [...]

I was looking for something like that, yes. Shouldn't that part be included (but more exhaustively) in the Diagnostics proposal?

I don't think so, since the globals and requirements on use are specific to the asio proposal. However the text associated with the globals is intended to intend up in the same chapter as 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.

So don't do "using namespace <ns containing error codes>" :) I think it's mostly a matter of taste, and I happen to prefer error:: over error_. Using a namespace also has the advantages of letting you alias it (e.g. e:: instead of error::), and you can do a "using <error-name>" into another namespace, etc. Cheers, Chris