Martin wrote:
Just a thought on the filesystem implementation.
Why not separate the path from the filesystem?
Let the path be a container for all kind of paths that follow the generic syntax explained in the boost::filesystem documentation.
That's already the case, no?
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)
I think you're XPath example is a bit bogus. How can you represent descentant::section[@id=foobar]/title with boost::path?
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);
Aren't those two mutually exclusive? You have the first on POSIX systems and the second on the win32 systems. If so, I don't understand how I can write portable code -- I will have to call different function on different pratforms, something like: #ifdef BOOST_WINDOWS if (exists(win32path(p)) #else if (exists(posix_path(p)) #endif which meean "messy #ifdefs" are just lifted to the user code.
bool exists( const path_base<win32reg<boost::fixed_string<100> > >& aPath);
This can be handled by class registry { bool exists(const fs::path&); }; Actually, I think it is very desired to have boost::path usable in more contexts than the filesystem. For example fs::path base("http://my_site.org"); ..... get_file(base / "foo" / "bar") ..... would be great. But I'm just don't sure this requires all that drastic changes. - Volodya