Christian Holmquist wrote:
Hi,
I found the filesystem headers to be very confusion, the grouping of classes and functions into headers seems to have been chosen arbitrary.
basic_recursive_directory_iterator in convenience.hpp? basic_directory_iterator in operations.hpp? shouldn't they use headers of their own, or at least use filesystem/iterator.hpp ?
create_directories is in convenience.hpp, but create_directory in operations.hpp? the free function extension(path) is in convenience.hpp, although I think most users would expect it to be a member of the basic_path class instead.
a rather highlevel (IMO) function copy_file is in operations.hpp, while others like change_extension is in convenience.hpp. what should I expect to find in convenience.hpp that is not in operations.hpp?
basic_filesystem_error, which is an std::exception derived class is in path.hpp, shouldn't it go into exceptions.hpp?
maybe someone could shed some light on how I should understand the api in order to include the correct header..
I agree that the separation of functions to headers, as you describe above, does not seem very logical. Probably it's better to include all headers.
More about path.hpp.. I think the use of iterator_facade in path.hpp is unfair to users, since it pulls in so much of complicated headers (have a look at iterator_facade.hpp) only to ease the task of implementing that path::iterator. I think that iterator_facade is a great tool for users that quickly wants to design a working iterator, but in a header such as filesystem::path that -should- be used everywhere where a file reference is needed, it should be rather lightweight (instead we use std::string, because it compiles with reasonable speed. I think we are not alone on this choice).
Do you have hard numbers about how much the user of iterator_facade affects compilation speed? Honest question -- I also find it unfortunate that compilation time is not a priority for Boost. - Volodya