Re: [boost] Filesystem Library mini-review

[Beman Dawes]

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.

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'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.

Your arguments are all reasonable, but I'm still not seeing beyond the disadvantages of trying to interpret the POSIX approach in C++. Do you have a firm proposal?

--Beman


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost