Boost logo

Boost :

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
> to ENOENT? If it is, enoent obviously wins over not_found_error as
> 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
> 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
> 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
> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at