Boost logo

Boost :

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-06-27 09:51:04


Peter Dimov <pdimov_at_[hidden]> wrote:
> Christopher Kohlhoff wrote:
> > IMHO the error_code class should have fewer member
> > functions, not more, and it should look more like a class
> > that emulates a builtin type. However this line of thinking
> > is probably driven by how I see this class being used wrt
> > asio.
>
> As long as there is at least one member, it's no longer a
> built-in-like. :-)

Elsewhere I suggested that errno_value() and sysno_value()
getters could be replaced by overloads of the free functions
to_errno and to_sysno. If the setters are also removed as
suggested in this thread, then that leaves a grand total of 0
named member functions :)

> I think that messages are fine as-is. Their primary audience
> is people who don't care about languages and locales (the same
> audience that finds what() useful). Programmers who do care
> will create their own mapping tables based on errno (or sysno,
> if they don't need portability for the error message module).

I'm not particularly fussed, but if we implement in terms of
strerror (or strerror_r) on POSIX platforms then we are already
getting locale support, but it's the C locale which determines
the error message.

> An operator== that compares both sysno_vaue() and
> errno_value() would allow the above to work reliably,
> though... as long as there is a single sysno in the OS, as you
> pointed out. :-)

Yes, this does makes me think that it might be better if an
error_code only had one true value, and that value is
represented by whatever category and error number it is created
with. It would only compare as equal to another error_code that
was created with exactly the same category and error number.
Conversion between errors in different categories should then be
explicit (using to_errno or to_sysno, say).

I don't know what implications this would have on the use of
error_code in the filesystem library, however.

Cheers,
Chris


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk