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

On Sat, Mar 23, 2013 at 9:55 PM, Joseph Van Riper < fleeb.fantastique@gmail.com> wrote:

On Sat, Mar 23, 2013 at 12:36 PM, Yakov Galka

...

wrote:

[...]

...

What are the separator characters in c:\x.txt, c:x.txt, or SYS$SYSDEVICE:[USER.DOCS]PHOTO.JPG:8?

* C:\x.txt: : for root, \ for branches (and branches between leaves). * C:x.txt: : for root, leading right into a leaf that would be wherever your sense of 'current directory' should be.

Whatever definition you give here, it won't let you parse the path with a simple split() or concatenate it with a simple join(). Therefore all such definition would be useless, and thus I see no point in talking about "separators" in a portable path library.

If someone entered this, you'd want to expand this to something like C:\my\current\folder\x.txt before working with it, unless you want a sense of 'current folder'.

But in order to do this you must have a 'current director', which means that you must query the filesystem. A path may point to a device that does not yet exist, like a drive that will be mounted later. The expansion must be done later, when you intend to *resolve* the path.

But that raises an interesting point I hadn't really considered... paths identified by a name, like Windows' %WINDOW% folder, etc. [...]

These are environment variables and I don't think mixing them with a filesystem library is a good idea. This would mix unrelated concepts. [...]

...

I claim that the "paths are strings" mindset is too simplistic, narrow minded and useless for defining path arithmetic. It is still true that we *do* want to represent paths as strings, and actually a library that would work with std::strings has its own right for existence. However, any paths library shall not have the word "separator" in its documentation for anything other than the platform specific parts.

I agree with this. The underlying representation should be more sophisticated.

I haven't said this. The underlining representation may or may not be a string. What I say is that the interface shall not be defined syntactically.

Manipulate a path as if it were something other than a string, and when you've finished manipulating it, call a function to expand it into a string (perhaps for use in an API that depends upon such a string, or for storage, or whatever). [...]

Exactly. I'm observing that the operating system provides an API that allow you to

traverse a file system in a manner like working with a tree (or forest if you prefer). [...] This is what I wanted to suggest.

I agree in general. What you describe is very similar to [Poco::Path]( http://pocoproject.org/slides/080-Files.pdf), which seems to get right many things boost didn't. -- Yakov