[boost] Re: New design proposal for boost::filesystem

From: Martin (adrianm_at_[hidden])
Date: 2004-09-06 03:33:24

> > If you want to add another path type (e.g. url) you would need to keep
> > track of the type inside the class and then do "if (type==url) ... else
> > ..." in all operations.
> 
> Not sure. Why appending "foo" path element to a URL is different from adding
> the same "foo" to a regular filesystem path? with ad

I was talking about operations. The filesystem operations doesn't necessary 
make sense for non-filesystem paths. If only one path type is used you can't 
get a compile time check that the operation works for the path type.

> If we take the approach that path is "root" + relative path, where "root" is
> an arbitrary string, then almost all kinds of path can be stored in
> boost::path.

agree but as someone else said, you can do it with std::string as well.

> Ok, let me ask another way: why
> 
>    exists(registry_path(p))
> 
> is better than
> 
>    exists_in_registry(p);
> 

type safety. There is no risk of sending a filesystem path to a registry 
operation or the other way around.

> > 
> > #ifdef BOOST_WINDOWS
> > #include "win32fs.hpp"
> > typedef path_base<win32fs> path;
> > #elif BOOST_POSIX
> > #include "posixfs.hpp"
> > typedef path_base<posixfs> path;
> > #endif
> > 
> > ...
> > 
> > if (exists(path(p))
> 
> Yes, it's possible. You essentially lift the #ifdefs: they are inside 'path'
> methods now and now they are around definition of 'path'. That will work,
> but I still don't understand why it's good given that win32 and posix are
> mutually exclusive. Do you think it would be good to compile both win32fs
> adn posixfs on all systems?

ofcourse not. You compile one or the other.

When I talked about messy #ifdefs I mainly meant the ones in the path class 
but they are not the main reason for the proposal.

It would be interesting to see how the current implementation extends into 
unicode. If it follows on the same way it would be "#ifdef UNICODE" in the 
path class and in the operations.

> > The current path implementation doesn't 
> > allow you to handle more than one type (i.e. winfs or posixfs). You can't
> > store a registrypath in a fs::path since it can't handle a hkey.. root.
> 
> Why? Can't I put literal "HKEY_CURRENT_USER" in boost::path?

You can store it as a root if you use a trailing ":". It will be treated as a  
windows device but for "HKEY_CURRENT_USER:software/xxx" has_root_path() will 
return false (the path class doens't expect relative paths on devices so some 
methods work others don't)

> I really think that win32/posix distinction should say as it is. For other
> types of path, I'm not sure. I *think* that boost::fs::path can accomodate
> all of them.
> Of course, if you stick URL into boost::fs::path, the name
> 'native_file_path' becomes questionable 

My idea was to have a layout like:

path.hpp - path_base class
fspath.hpp - path class for filesystems. Conditionally includes win32fs.hpp or 
posixfs.hpp
fsoperations - filesystem operations. Conditionally includes win32oper.hpp or 
posixoper.hpp
urlpath.hpp - path class for urls
urloperations.hpp - operations on url paths.