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.
Rob
Susquehanna International Group, LLP
http://www.sig.com