Re: [boost] [system] system-0.2 request for comments

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-07-24 21:58:33

"Christopher Kohlhoff" <chris_at_[hidden]> wrote in message 
news:20060724133406.3655.qmail_at_web32610.mail.mud.yahoo.com...
> Hi Beman
>
> Beman Dawes <bdawes_at_[hidden]> wrote:
>> * Class error_code now supports additional categories of
>> errors, such as those that may bubble up from asio. I'll be
>> watching for for a response from Chris to make sure this meets
>> asio's needs.
>
> Looks good! I have just uploaded a version of asio that has been
> modified to use error_code and system_error where appropriate.
> It's in the vault, in the System directory.
>
> Just a few minor things:
>
> - the system_error::what() function is defined in
>  system_error.hpp without being inline, causing multiple
>  definition linker errors.

Nuts! That's about the millionth time I've made that mistake.

Will fix.

> - I'm not sure about the category names errno_ec and native_ec,
>  since I keep reading the "ec" as error_code. I don't have any
>  good suggestions, except perhaps more verbose names likes
>  errno_category and native_error_category.

I started out with errno_category and native_error_category (or something 
similar), but found them overly verbose in some real code I converted.

> - The Jamfile is doing something strange when I try to link the
>  boost_system library from the asio unit test Jamfile, but it
>  works fine when used from non-test Jamfiles.

Hum.... Not sure what to make of that. What error are you getting?

> - The boost::identifier iostream operators aren't always working
>  correctly with VC8. For example, try compiling the asio
>  serialization example, which gives errors saying operator>>
>  is ambiguous.

They aren't that critical, so could be removed if necessary. Perhaps some 
enable_if expert could take a look and see how to make them less likely to 
cause ambiguities.

> - error_code::new_category probably needs to be made
>  thread-safe, or the limitations on when it can be called
>  should be documented.

Do we have a portable way to make it thread safe?

> - You might want to add special handling when converting the
>  success errno (i.e. 0) to a string on POSIX. The strerror
>  function doesn't give you a string for it, so you end up with
>  "EINVAL", which is a bit surprising.

To say the least. I'll add some special handling. Good catch!

> Converting asio to use this stuff was a non-trivial exercise, so
> I can confidently say I now have extensive experience using
> these classes ;) I'm happy with the interface -- it's clean and
> easy to use, particularly when it comes to defining new error
> categories.

Good, it makes me really happy to hear you say that:-) I was worried that I 
might be so deep in the forest I could only see the trees.

Thanks for the report,

--Beman