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

4 Sep 2004


      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@alinoe.com>