Re: [Boost-users] filesystem headers

From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-05-28 15:34:27

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 <time.h>

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
<c.holmquist_at_[hidden]> 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users