From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-31 16:36:37
From: Darin Adler [SMTP:darin_at_[hidden]]
> 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
> > 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
> that claims it can compare paths reliably without hitting the disk. But
> with hitting the disk, since disk contents change, path equality can
> so I think it's not really suitable for ==.
I'd find a class that does this "abstract" pathname comparison quite useful.
The overhead involved in a version that hits the disk for everything would
be pretty high. Furthermore, the only context I can think of in which I'd
need that strong sort of comparison is when writing a disk utility.
However, if I'm writing such an application, I'd likely be using OS APIs
In the general case, I'd want (and have used, in my own versions of such a
class) to be able to build pathnames from operations on others. For
example, I'd want to be able to concatenate one (relative) pathname to
another (possibly absolute) pathname. I'd want to be able to extract the
filename from a pathname, or add a filename to one, etc.
> 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
> sorts of "un-keepable promises".
All of those manipulations would be string-like operations, so yes,
std::string would work. But...
> There are some arguments in favor of classes rather than a string, though.
> The ability to overload. The greater clarity of purpose. Reducing the
> 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.
Those arguments are completely compelling. They demand a separate class.
Susquehanna International Group, LLP
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk