Yakov Galka wrote:
On Sat, Mar 23, 2013 at 2:01 PM, Alexander Lamaison
wrote: [...] Is it time for a Boost.Filesystem v4 to result from an in-depth discussion on here? I'd hope it would take the best of v3 while removing some of the hurt it introduced in the process. For example, my top two issues are: - unclear generic/native path handling - methods returning a 'path' for stuff that isn't a path but just needs a unicode string
Perhaps people can reply to this thread with any gripes they have?
See a related thread of things that boost.filesystem got wrong:
http://boost.2283326.n4.nabble.com/boost-filesystem-path-frustration-td46417...
I quite love the idea from that thread of making filesystem a first class abstraction. Although if I'm using a posix_filesystem object on windows to manipulate posix paths I obviously can't call operating system routines to do the work. And in this situation I imagine I couldn't open the file without converting the posix_filesystem::path to a windows_filesystem::path. Would this necessitate 2 implementations of posix_filesystem? One for when it is the native filesystem and one for when it isn't? I'd also like to see more ideas about how a virtual filesystem object would work. Sounds similar to PhysicsFS. http://icculus.org/physfs/