From: "Beman Dawes" <[EMAIL PROTECTED]> > > 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? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
