Boost logo

Boost :

Subject: Re: [boost] [Filesystem] v3 path separator changes
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2013-03-23 13:57:09


Yakov Galka wrote:
> On Sat, Mar 23, 2013 at 2:01 PM, Alexander Lamaison <awl03_at_[hidden]>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-td4641734.html
>

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/


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk