I have to second pretty much everything said in this post. I have found the boost::filesystem headers quite heavy. In my own code I do use boost::filesystem because its portability is important, however I use it as implementation detail. I've made that decision for two reasons: First, I find the separation between path and wpath unfortunate. I much prefer the simpler utf8 encoding. Second, for me it is unacceptable (showstopper really) to include this much code just to be able to say in a header file: void foo( boost::filesystem::path const & ); My solution is to use std::string to store paths and to define path interfaces, and use wrappers that forward the call to boost::filesystem, like so: bool create_directory( std::string const & s ) { return create_directory(wpath(utf8_decode(s))); } Of course, having the type system reflect the fact that a string is not just a string but is really a file path is a good thing, but compare the boost::filesystem headers to something like this: #include <string> #include bool create_directory( std::string const & ); bool create_directories( std::string const & ); bool path_exists( std::string const & ); void path_rename( std::string const & from, std::string const & to ); bool path_remove( std::string const & ); int path_remove_all( std::string const & ); void copy_file( std::string const & from, std::string const & to ); time_t path_last_write_time( std::string const & path ); void path_set_last_write_time( std::string const & path, time_t ); bool path_is_directory( std::string const & ); std::string path_extension( std::string const & ); std::string path_base_name( std::string const & ); std::string path_branch_path( std::string const & ); std::string path_change_extension( std::string const &, std::string const & extension ); std::string complete_directory_path( std::string const & ); std::string complete_file_path( std::string const & ); The above API is from my own header called path_operations.h, which basically contains wrappers for what I personally have needed from Boost Filesystem. Maybe my approach would be better if I had a path type that wraps std::string and has the invariant that its content is a UTF8-encoded path, but this still has somewhat questionable benefits, because the different path operations have different preconditions that go far beyond the "path" invariant. Regards, Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode On Wed, May 28, 2008 at 11:06 AM, 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..

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). The inclusion of iosfwd only for stream operators is again not what I would prefer, better off putting that stuff in path_io.hpp is type_traits/is_same.hpp, throw_exception.hpp, static_assert.hpp used in path.hpp at all?

Sorry for all the complains, I wouldn't write them unless I really, really wanted to use boost::filesystem. Finally there's a better way to do file and path operations in c++, but it's not practical in its current form. I've been trying with no success incorporating filesystem more in our very large code base, but compilation times and confusion about headers have made me redraw most of that code.

Regards, Christian _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

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