Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-09-04 03:55:33


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk