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

From: Carlo Wood (carlo_at_[hidden])
Date: 2004-09-03 22:18:59

On Fri, Sep 03, 2004 at 07:54:29AM +0000, Martin wrote:
> Just a thought on the filesystem implementation.
> 
> Why not separate the path from the filesystem?

Isn't it already separated?  fs::path just hold 'values'
and then you have the 'operations' as an addition, separated
from it.

> Let the path be a container for all kind of paths that follow the generic 
> syntax explained in the boost::filesystem documentation. 
> 
> Then use implementation classes that handles root name and conversion to 
> native strings etc.
> 
> The benefits would be:
> 1. The path can be used for other things than filesystems (XPath, Win32 
> registry)

So can std::string.  I am not sure that this is a benefit.

> 2. Operations can be implemented selectivly for different types (No need for 
> the current messy #ifdefs)
> bool exists( const path_base<posixfs<std::string> >& aPath);
> bool exists( const path_base<win32fs<std::wstring> >& aPath);
> bool exists( const path_base<win32reg<boost::fixed_string<100> > >& aPath);

That would move the #ifdefs to the application.  I like it better
to have two types 'native' and non-native (relative) rather than
have to write code that needs to use a different type explicitely
for every OS that I want to support in my code.

> 3. Easy to expand the functionality for specific tasks without touching the 
> boost headers.
> 
> The implementation could look something like:
> 
> template <class ImplT>
> class path_base : private ImplT {
>   public:
>     typedef ImplT::string_type string_type;
>     path_base() : ImplT() {}
>     // all path operations as in current implementation
>     ...
>   private:
>     string_type m_path;
> };
> 
> //
> // implementation for win32 filesystem
> //
> template <class StringT>
> class win32fs {
>   // root-name   ::= root-drive | root-share | root-device
>   // root-drive  ::= char ":"
>   // root-share  ::= "//" name 
>   // root-device ::= name ":" 
>   protected:
>     typedef StringT string_type;
>     win32fs() { }
>     string_type make_generic(const string_type::value_type* src);
>     string_type native_file_string(const string_type& m_path) const { return 
> algorithm::replace_all_copy(m_root + m_path, "/", "\\"); }
>     ...
>   private:
>     string_type m_root
> };
> //
> // implementation of posix filesystem
> //
> template <class StringT>
> class posixfs {
>   win32fs() { }
>   string_type make_generic(const string_type::value_type* src);
>   string_type native_file_string(const string_type& m_path) const { return 
> m_path; }
>   ...
> }
> 
> #ifdef BOOST_POSIX
> typedef path_base<posixfs<std::string>> path;
> #else
> ...

I fail to see how this all would address the same problems
as that I tried to address by the introduction of an explicit
native and relative path types - the latter of which would
allow automatic completion by tieing it to a (native) absolute
path.

-- 
Carlo Wood <carlo_at_[hidden]>