Boost logo

Boost :

From: Darin Adler (darin_at_[hidden])
Date: 2002-01-31 16:26:29

On 1/31/02 1:09 PM, "David Abrahams" <david.abrahams_at_[hidden]> wrote:

> I think this might be a good argument for a pathname class:
> assert( std::string("a/b/../c") == std::string("a/c") );
> Of course, determining path equality reliably is much more complicated than
> this, and in general you can't do it with just relative paths:
> path("../a/b/c") ==? path("b/c")

It's a very slippery subject. I would not recommend having a pathname class
that claims it can compare paths reliably without hitting the disk. But even
with hitting the disk, since disk contents change, path equality can change,
so I think it's not really suitable for ==.

I think this comparison issue is more of an argument in *favor* of using a
string rather than a custom class. Using a string makes it more clear
exactly how "non-magic" the pathname object is. A pathname class implies all
sorts of "un-keepable promises".

The same issue came up in another project I'm working on, where there was a
URI object. But in the end we found that interfaces that treated URIs as
strings were far more useful and clear.

There are some arguments in favor of classes rather than a string, though.
The ability to overload. The greater clarity of purpose. Reducing the chance
that you'll accidentally pass a URI to a function that expects a pathname,
or a relative pathname to a function that only works with full pathnames.

    -- Darin

Boost list run by bdawes at, gregod at, cpdaniel at, john at