Boost logo

Boost :

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


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

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 {
        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:

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

- Volodya

Boost list run by bdawes at, gregod at, cpdaniel at, john at