Boost logo

Boost :

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
> 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>?
> 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
> errors.
> >Note that there are two issues here. First, whether the
> portable error
> code
> >reported by the library matches the numeric value of the
> corresponding
> >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.
> The "already standard" argument you make below pushes toward
> including
> <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:
> not_found_error,
> not_directory_error,
> Would you prefer:
> enoent,
> enotdir,
> 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
> 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?
> 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, gregod at, cpdaniel at, john at