Re: [boost] Re: path::leaf()

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-25 19:35:45

At 03:55 PM 8/21/2003, David Abrahams wrote:

 >Beman Dawes <bdawes_at_[hidden]> writes:
 >
 >> At 08:31 PM 8/19/2003, David Abrahams wrote:
 >>  >
 >>  >It surprised me a bit that leaf returns a string instead of a path.
 >>
 >> The rule isn't entirely obvious. If a decomposition function can
 >> possibly return more that one element, it is returned as type path. If
 >> at most a single element is returned, the return type is std::string.
 >
 >It may not surprise you, but the easy translation between paths and
 >strings really rubs me the wrong way.  Practically the only reason I'm
 >using the path class at all is to increase the level of abstraction
 >and self-documentation of the code I'm writing -- I think it's foolish
 >to pass around something called std::string when it really represents
 >a file path.  A single component of a path is still a path, and it
 >shouldn't devolve into a string.
 >
 >I'm rewriting some Java code in C++ which has a "Directory"
 >abstraction, that lets you open files in that directory.  I want those
 >functions take path parameters.  I want to assert that they're leaf
 >paths.  Having to write:
 >
 >    assert(path(p.leaf()) == p)
 >
 >or
 >
 >   assert(p.leaf() == p.string())
 >
 >instead of:
 >
 >   assert(p == p.leaf())
 >
 >really feels odd to me.

What about:

     assert( p.branch_path().empty() );

Isn't that closer to what you are trying to express?

 >>  >Shouldn't
 >>  >
 >>  >   "foo/bar"/p.leaf()
 >>  >
 >>  >work?
 >>
 >> Yes, via the automatic conversion. I just added a test case to
 >> path_test to verify that. Yes, it does work. I expect there would
 >> have been scads of bug reports if it didn't work.
 >
 >Whoa.  What code and compiler did you test that with?

Ah! I corrected your code first so that "foo/bar" was a path. There is no 
operator/ for string arguments, of course.

--Beman