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

On Sat, Mar 23, 2013 at 8:01 AM, Alexander Lamaison wrote:

Yakov Galka writes:

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.

Perhaps. For my needs, v3 is an improvement over v2, which I found just generally annoying. All I really needed out of a filesystem library is a way to work with the filesystem on the native operating system, without having to constantly look up how to do anything from the documentation. I felt version 2 focused overmuch on relatively unusual cases and made it very annoying for the common case. Version 3 corrected that, but at some expense, apparently. So now that I'm happy, some of the other folks responding to this thread are not. I've often wondered about the design of filesystem, to be honest. It seems to me as if it could be improved to be more generic, and yield some other tools that could go beyond being helpful in working with file systems.

Perhaps people can reply to this thread with any gripes they have?

Well, I wouldn't describe this as a gripe exactly, just an idea for a different approach, if it tickles anyone's fancy. I have never seen a file system that wasn't, really, a tree with branches and leaves. It can have more than one base, but ultimately, it's a tree. As such, it feels to me like a more natural way to work with the file system is through an object that represents trees, and functions that help you work with the tree, or represent a particular path on the tree as a generic string, with a particular separator character (or characters). With a sort of understanding that the base is different from a branch, which is itself different from a leaf. (E.g.: in the Windows file system, the base represents drives or network shares, a branch is a folder, and a leaf is a file). With that approach, you could also represent the Windows registry using the same objects (just a different backend to handle the obviously different API calls). Or SMNP OIDs. Or a web site's paths. You could also do some other things that get rather intriguing, like serializing a representation of your tree to disk, or comparing pairs of these trees to find differences. Which, in a different company, was something I needed to do, but I confess that it's probably not a common use for trees... although it's common enough that I saw a paper written on the subject in the ACM's library. If boost first had a library that best presented tree representations of existing objects, then another layer of objects that helped build this tree or turn it into a string representation for specific paths for different kinds of needs (windows OS, VMS, web site, etc), it might offer the power and flexibility that people seem to want out of this library without the headaches of an API that makes you jump through non-intuitive hoops. Or does boost already have something like this and I've just been missing it? - Trey