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
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