From: Iain K.Hanson (iain.hanson_at_[hidden])
Date: 2002-12-13 11:42:04
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Beman Dawes
> Sent: 13 December 2002 15:31
> To: Boost mailing list; Boost mailing list
> Subject: Re: [boost] Filesystem Library mini-review
> At 08:19 AM 12/13/2002, Peter Dimov wrote:
> >From: "Beman Dawes" <bdawes_at_[hidden]>
> >> Part of the problem is that there is no guarantee that
> the macros will
> >> available in <cerrno>.
> >Yes, that's true in theory, but in practice, is there a
> platform that
> >doesn't have the macros in <cerrno>?
> It is messier than that. For example, Microsoft supplies
> cerrno with only
> some of the macros. EBUSY, ENOTDIR, ENOTEMPTY, and others are missing.
And many unixes don't make them available without an environment
variable or an additional #define.
> The filesystem library also needs one or two additional codes
> for its own
> >Note that there are two issues here. First, whether the
> portable error
> >reported by the library matches the numeric value of the
> >macro. Second, how does the exception.hpp header make the constants
> >available, i.e. does it #include <cerrno> (with <cerrno>
> guaranteed to
> >the macros), or does it provide its own aliases.
> The "already standard" argument you make below pushes toward
> <cerrno>. Yet usual C++ practice would be more like the enum
> in the current
> header, and not including <cerrno>.
> Would you see any value in providing aliases with names that map more
> closely to the POSIX names?
> For example, instead of:
> Would you prefer:
> If so, why?
I strongly prefer the former. One of the first things I do when
having to deal with errno is map the errno names to something
readable like not_found_error. I can never remember the posix
names and many unix programmers resort to the man page to look them
up ( not caring if they are the posix names of the implementation
> I'm wondering if part of your worries could be caused by the
> lack of a
> filesystem function similar to POSIX perror()?
> >> 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
> >> 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
> >scheme. Why reinvent the wheel? Will we do any better?
> We might. The POSIX errno scheme doesn't seem all that strong to me.
Agreed. I've given a fair ammount of though to this over the past year
( whilst working on sockets). The conclusion I came to was that I would
rather have a standard C++ name on what ever platform I work on than
keep having to look them up on every platform.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk