From: "Peter Dimov" <[EMAIL PROTECTED]> I am replying to my own post in order to clarify some points.
> From: "Beman Dawes" <[EMAIL PROTECTED]> > > 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
