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