I replied yesterday but it looks like Gnus ate it.
Klaim - Joël Lamotte
My use case is to be able to easily choose between real file system and archive file system at runtime. To implement archie file work I currently use PhysFS [1].
However I have several totally different projects with this need of runtime choice of filesystem and currently I have to add project-domain-specific file manipulation layers to each project which is therefore implemented twice, once with boost::filesystem and the other with PhysFS. That's a lot of time spent on making sure they do the same things and it is easily error prone. A solution to help me write my project-specific algorithms once would be very helpful.
If we were to go ahead with my proposal, you could write a thin layer on top of PhysFS to make it a model of FilesystemConcept. Boost.Filesystem would also model this concept, and then write your algorithms once for both of them.
Also, it seems that it would the solve the same problems for std::filesystem? It was a concern I had recently when thinking about it.
The impeding standard was what caused me to release the draft now. I'd like to get this into Boost.Filesystem before the standard (which is based on it) is frozen.
Question: it is not totally clear to me what the proposal wants to do with the boost::filesystem::path class exactly.
True, I did gloss over this a bit.
The example suggests that boost::filesystem::path would be usable for any filesystem implementation.
Perhaps I overstated that. What I was trying to say was that it should be possible to use the same path class for multiple filesystems. That may mean reusing boost::filesystem::path, if its behaviour makes sense for that filesystem, or something else. The only case I can think of where *every* boost::filesystem::path method is applicable, would be when mocking the local filesystem. Even a filesystem implementation that connects to a remote filesystem using it's native path format, would not be able to use boost::filesystem::path because platform-specific methods would render the answer based on the *local* platform, rather than the remote one. A path class for such a filesystem would be almost identical to boost::filesystem::path, except for basing its platform-specific decisions on the remote platform.
In which case, do you suggest to remove absolute() and cannonical() from boost::filesystem::path so that it would only be possible to get these versions using one of the namespace functions overload of the same name, one for local_filesystem(), the other taking a filesystem as parametter?
absolute() and canonical() are already free functions, so these would just be overloaded or turned into filesystem object methods (whichever API design we choose) just like the other operations. But you probably mean make_absolute(). As far as I can see, this is the only filesystem-instance-specific method in boost::filesystem::path and would, ideally, not be there at all. However, in practice, it does no harm because it won't be in FilesystemPathConcept, so generic code cannot rely on it. Models of FilesystemPathConcept are permitted to have local-platform-specific behaviour for certain methods. For example, native() is allowed to vary the appearance of the path it returns based on local operating-system conventions. For example, a ZIP-file filesystem should be allowed to format paths using backslashes on Windows. However, filesystem-instance-specific behaviour should not be permitted as (apart from the local filesystem), that requires access to a filesystem object instance. Glad to hear any further thoughts. Alex