Re: [boost] [Filesystem] Proposal: make filesystem generic-programming friendly

Subject: Re: [boost] [Filesystem] Proposal: make filesystem generic-programming friendly
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2014-01-09 19:34:46

I've hit issues similar to the pointed ones, so I'm interested in such a
solution.
As a user I agree that being able to use the whole path/aglorithms on
different kinds of filesystems would simplify greatly my current work.

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 the proposal is really applicable without any backward incompatibility,
I'm open to test it ASAP in my current projects (if an implementation
exists).
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.

Question: it is not totally clear to me what the proposal wants to do with
the boost::filesystem::path class exactly.
The example suggests that boost::filesystem::path would be usable for any
filesystem implementation.
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?

[1] http://icculus.org/physfs/