Since the slash or slashes in that case are extraneous, I would also say option 2 is the way to go. Remove the trailing slash because it was probably not intended in the first place. The only question I would have is about the path that is simply "//" or natively in the windows world "\\". In the windows command prompt changing to those two directories yields the following results. C:\Documents and Settings\blah>cd \\ '\\' CMD does not support UNC paths as current directories. and C:\Documents and Settings\blah>cd \ C:\> So if you were to trim the trailing slash in "//", it could potentially have different results in windows since it sees the "\\" as the beginning of a UNC path. Or I could just be looking to far into it, and this isn't a problem at all? - Dave "Beman Dawes" <bdawes@acm.org> wrote in message news:d7mvgn$jnu$1@sea.gmane.org...
I'm working to align the Boost.Filesystem generic path grammar with the POSIX specification. Doing so clarifies the specification of the library, and ensures that all native paths for both POSIX and Windows will work correctly. (Windows follows the POSIX conventions in some of the corner cases involved.)
The particular cases involve extra slashes in paths. For example, "/foo//bar//". I was surprised to find that such a path is well-defined for POSIX and Windows, with a meaning of "/foo/bar/." In other words, multiple slashes treated as a single slash, and paths with a trailing slash treated as if a period was appended. The rules for more than two leading slashes are a bit more complex - for POSIX they are treated as a single slash, for Windows that is an invalid path.
Question: what should path("foo//bar//").string() yield?
1) "foo//bar//" 2) "foo/bar/" 3) "foo/bar/."
(1) follows the rule that the path string is always exactly as input. Desirable in that if a platform actually implements something a bit different from the POSIX specs for multiple slashes, implementations will behave as expected for the platform. Downside is much more complex implementation (because many more functions have to be able to cope with multiple slashes) and more complex testing.
(2) Desirable in that if a platform actually implements something a bit different from the POSIX (and Windows) specs for multiple slashes, implementations will behave portably and correctly in a POSIX (and Windows) sense.
(3) Desirable in that for all three options directory iteration will return three elements - "foo", "bar", "." - so it is a bit counter intuitive for the "." not to appear in the string() results. Not a strong argument.
I'm leaning toward (2). Any comments?
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost