Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-21 14:55:30


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.

> >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?

    # include <boost/filesystem/path.hpp>
    void f(boost::filesystem::path const&p)
    {
        boost::filesystem::path q = "foo/bar"/p.leaf();
    }

vc6 - fail
vc7 - fail
vc7.1 - fail
cwpro7.2 - fail
cwpro8.3 - fail
intel5 - fail
intel6 - fail
intel7 - fail
mingw-2.0 (gcc-3.2) - fail
cygwin gcc-2.95.3 - fail
borland-5.5.1 - fail

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk