RE: [boost] pathname manipulation

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
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'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
anyway.

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
all
> 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
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.

Those arguments are completely compelling.  They demand a separate class.

Rob
Susquehanna International Group, LLP
http://www.sig.com