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 <ybungalobill@gmail.com
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