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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-09-07 06:19:30

Hi Martin,

[BTW, may I gently ask you to put your full name on your messages?]

>> > If you want to adimportantr 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.

I think we probably need to distinguish between two cases. First is URL
paths:

   file:///foo
   http://boost.org
   man:strcmp

It's not currently supported. I think URL should be represented with one
class (which can be even fs::path). If URL can to constructed from user
input, and if new protocols can be added dynamically, it does not make
sense to hardcode the protocol.

The second case is 'generic paths' -- just a sequence of element, which is
not related to filesystem. The example you give is registry. I don't know
what other cases are there, so it hard to tell how important it is. Yes,
with separate "registry_path"  you'll get more typechecking, but to figure
out how much overlap this class will have with 'path', you'd need to write
it. 

BTW, you don't need to use path_base<registry_path>, you can use:

   class registry_path : private path_base {   
   };

which I find a bit simpler.

Another, BTW, program_options will have registry support sooner or later, so
maybe this use case is not imptorant ;-)
   
>> 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.

Ok, for registry vs. filesystem, I think it makes sense. For different kinds
of URL -- likely not.

>> > #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.

Everybody has different opinion on this. I'd prefer:

  class path {
  public:
        path(const char*);
        path(const whar_t*);
        string native_file_string();
        wstring native_file_wstring();
   };

Since some parts of code might prefer Unicode, and others ascii.

>> > 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)

Yea, I've suggested in a previous email that root handling code should be a
bit refactored. Instead of looking a the string, has_root_path() should
return a flag that was initialized during construction.

>> 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.

I think that one of the primary issue with URL path is the need for
dynamically pluggable protocol handlers. Something like in KDE:

  http://www.heise.de/ct/english/01/05/242/
  http://developer.kde.org/documentation/library/cvs-api/kio/html/namespaceKIO.html
  http://developer.kde.org/documentation/library/cvs-api/kio/html/classKIO_1_1SlaveBase.html#a39

Hmm... maybe I should find more time for Boost.Plugin that I've started to
draft some time ago.

- Volodya