Re: [boost] Filesystem Library mini-review

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-12-16 08:35:48

From: "Peter Dimov" <pdimov_at_[hidden]>

I am replying to my own post in order to clarify some points.

> From: "Beman Dawes" <bdawes_at_[hidden]>
> > 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?
>
> You haven't addressed an important question, is not_found_error/enoent
equal
> to ENOENT? If it is, enoent obviously wins over not_found_error as
otherwise
> people need to maintain a mental map. [...]

On second thought, people need to maintain a mental map anyway, since POSIX
names aren't very intuitive. Therefore, I see nothing wrong with
exception.hpp providing better aliases.

> > 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?
>
> But we don't need to interpret anything. POSIX has already done the work
for
> us. :-)

To clarify: the current situation requires the filesystem library to
interpret system-specific error codes. Adopting the POSIX values would
eliminate that need on some important platforms, with no downsides.

> My proposal is
>
> - portable error codes returned by the filesystem library shall have the
> same meaning as the corresponding E*** macro, if one exists. In
particular,
> std::strerror(), or an equivalent (the user may already have a fully
> localized replacement) should produce the right error message.
>
> - exception.hpp shall make the E*** macros available (whether it does so
by
> including <cerrno> is unspecified.)

I withdraw this point. Users that need E*** can easily include <cerrno>
themselves. There is no need to require the filesystem library to make the
names available.