Re: [boost] [Filesystem] v3 path separator changes

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/