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
> > 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk