On Sun, Feb 8, 2009 at 5:12 AM, Walter Landry <wlandry@caltech.edu> wrote:
Beman Dawes <bdawes@acm.org> wrote:
A prototype implementation of version 3 of Boost.Filesystem is available for comment.
This was also true in the old version, but one thing that bothers me is that the filesystem library defines a number of types: regular_file, directory_file, fifo_file, symlink_file, etc. Why does it append "_file" to the end of all of the names? Why is it not just regular_file, directory, fifo, symlink, etc.? The corresponding identification functions are named is_directory and is_symlink, which seems inconsistent.
It is inconsistent. _file was appended to avoid polluting the namespace with enumeration constant names "regular", "directory", etc, that might later be needed for other purposes. In C++0x, the preferred practice for such constants is probably going to be to use a scoped enum: enum class file_type { status_unknown, file_not_found, regular, directory, symlink, block, character, fifo, socket, type_unknown }; That's a lot more satisfying. We can emulate that approach in C++03 like this: #ifndef BOOST_NO_SCOPED_ENUM enum class file_type { status_unknown, file_not_found, regular, directory, symlink, block, character, fifo, socket, type_unknown }; typedef file_type file_type_enum; #else namespace file_type { enum types { status_unknown, file_not_found, regular, directory, symlink, block, character, fifo, socket, type_unknown }; } typedef file_type::types file_type_enum; #endif Is such a scoped enum approach worth taking? I haven't made up my mind; I'd like to think about it for a few days and also see what could be done to preserve existing code.
Cheers, Walter Landry wlandry@caltech.edu
p.s. I noticed that you changed the names of "nlink" and "readlink" to the more clear names "hard_link_count" and "read_symlink". This might be needlessly confusing for those familiar with Unix, but even Ken Thompson said that, if he had to do it over again, he would have spelled "creat" with an "e" ;)
I really prefer the clearer names:-) Thanks, --Beman