Re: [boost] [filesystem] Generic path grammar corner cases

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-06-02 15:13:46

From: "Beman Dawes" <bdawes_at_[hidden]>
> 
> 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?

I think the correct answer is (1).  The reason is that is what
the client gave you.  Why modify it?  It may be surprising to get
something different back.

It is reasonable to provide a normalization function that can
make any desired tweak to a path, thus externalizing and making
explicit the normalization.  This also enables creating several
normalization functions rather than hard coding one in path.

OTOH, (path("foo/") / "/bar").string() should yield "foo/bar"
since this is a case of the user asking path to do the
concatenation.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;