From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-31 16:44:28
From: Matt Austern [SMTP:austern_at_[hidden]]
> There's also a definitional problem. Suppose we're on Unix, and we've
> got 'ln a b'. Would we expect path("a") to equal path("b"), since they're
> just two names for the same file? My intuition is no, but my intuition
> starts getting uneasy when you imagine that a and b are two links to
> the same directory, and when you start thinking about a/c and b/c. And
> then I get even more uneasy about VMS logical names, which are somewhere
> in between Unix symbolic links and Unix environment variables. I'm not
> sure I know what it means to ask whether or not two paths are the same.
When manipulating a pathname, I don't expect anything more than std::string
would provide, in terms of comparisons, etc. To deal with
filesystem-specifics, and the dynamic nature of a filesystem (which allow
for the contents to change from the time you make a query to the time you
try to write to it), I'd work with a separate class that uses pathname
objects to specify the filesystem objects to manipulate.
Given that approach, I wouldn't care if there were a couple of different
pathname classes to account for the differences among filesystems, so long
as they were sensible and reasonably similar (metaprogramming-friendly), and
that the filesystem object classes work with the corresponding pathname
types. Where it makes sense, a filesystem object class might work with
several pathname types, translating to/from the native and external pathname
representations as needed.
IOW, I don't see the need for a one-size-fits-all solution. There are too
many differences to account for to make that work well.
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