Boost logo

Boost :

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2006-11-10 08:56:29

Christopher Kohlhoff wrote:
> Hi Johan,
> Johan Nilsson <r.johan.nilsson_at_[hidden]> 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 in N2054 for
> more detail:

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at