"Alisdair Meredith" <alisdair.meredith@uk.renaultf1.com> wrote in message news:d7n3g2$1h8$1@sea.gmane.org...
Beman Dawes wrote:
Question: what should path("foo//bar//").string() yield?
1) "foo//bar//" 2) "foo/bar/" 3) "foo/bar/."
I'm leaning toward (2). Any comments?
What happens if the user wants to start concatenating filenames on the end of the path? Ideally they will use library facilities of course <g> But if they insist on doing it the hard way, (2) 'just works', (3) requires additional parsing to remove the trailing '.' and (1) is still the oddball - for both good and ill.
For me that makes it a call between (1) and (2), and I am in favour of (2) as I prefer to have a single, well defined portable representation - not something else I will need to parse again with yet another library.
I think this means we are in agreement <g>
Good. I needed a reality check. I've got my nose so buried in the trees it would be easy to miss the forest. I guess the question comes down to this: In spite of POSIX specs and Windows experiments to the contrary, are there ever valid paths with multiple slashes (other than at the start)? That may be the same issue as what to do for an operating system where slash is valid and useful file or directory name. I think the example someone gave was a filename like "data as of 1/2/2005". A fix for both issues would be to introduce an escape sequence which means "slash and I really mean it", or an escape path prefix which means "don't modify this path in any way." Both of those seem like ugly warts, and I've been avoiding them until someone comes up with a compelling use case. I would hate to do something ugly that may have no practical use whatsoever. Hum... Gears clank in brain for awhile... In the past, whenever I thought about escape sequences, I assumed we would have to invent a new escape sequence, and that would be quite messy. But what about hijacking one of the existing escape sequences? Of all the C++ escape sequences, '\a' stands for BEL, and would seem to have the least probability of ever being a valid character in a path. It isn't valid at all for some OS's. If Boost.Filesystem hijacked it as an escape sequence meaning ""slash and I really mean it", we could use option (2) with all its advantages, yet if someone desperately needs more slashes for whatever reason, they have a way of doing so. Thoughts? --Beman