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... http://developer.kde.org/documentation/library/cvs-api/kio/html/classKIO_1_1... Hmm... maybe I should find more time for Boost.Plugin that I've started to draft some time ago. - Volodya