|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-12-13 08:19:54
From: "Beman Dawes" <bdawes_at_[hidden]>
>
> Part of the problem is that there is no guarantee that the macros will be
> available in <cerrno>.
Yes, that's true in theory, but in practice, is there a platform that
doesn't have the macros in <cerrno>?
Note that there are two issues here. First, whether the portable error code
reported by the library matches the numeric value of the corresponding EXXX
macro. Second, how does the exception.hpp header make the constants
available, i.e. does it #include <cerrno> (with <cerrno> guaranteed to have
the macros), or does it provide its own aliases.
> That's messy for Boost; we would have to provide
> our own and configure accordingly.
Depends on whether we target a platform where <cerrno> doesn't have the
macros. Do we?
> It might also be messy for
> standardization; its seems to have a lot of trouble when multiple
> committees start specifying the contents of the same header.
On the other hand, ignoring other well established standards isn't a good
thing either, from standardization point of view.
> The final
> worry about a POSIX based scheme is that it might mislead users into
> thinking every operating system can deliver exactly the POSIX errors and
no
> others. That isn't the case.
I don't see the problem. Any kind of a portable error scheme can mislead
users into thinking that all OSes report the same set of errors (and in
general, any portable API can mislead users into thinking that all OSes
support the same functionality.) We already have a standard portable error
scheme. Why reinvent the wheel? Will we do any better?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk