RE: [boost] Re: the first version of abstract path manipulation class (interface)

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-25 12:16:29

From:	Ken Hagan [SMTP:k.hagan_at_[hidden]]
> 
> From: "George A. Heintzelman" <georgeh_at_[hidden]>
> 
> > VMS is definitely really weird. A typical fully-specified VMS filename
> > might look something like this:
> >
> > DISK$SCRATCH:[GEORGE.PROJECT1.DAT]BIG_DATA_FILE.NTP;5
> >
> > The general format is:
> >
> > Device:[directories.dot.separated]filename.extension;version_number
> 
> > I have always thought that handling VMS, without losing the ability to
> > use a significant VMS-specific feature, would be a real challenge to
> > any pathname utility. Most of the ports of Unix programs that I have
> > seen ignore version numbers completely, and are rather clumsy around
> > extensive use of logical devices and logical names.
> 
> introduced to support the Mac's resource and data forks. I suppose
> that means the Mac also has its little twists.
> 
> Mainframe OSes have yet more ways of naming files, not all of which
> have any concept of a directory. Someone must maintain a list of

In order for this effort to be accepted into Boost, must it deal with
filesystems that diverge dramatically from Unix in pathname conventions?
That would certainly be necessary were this to be included in the C++
Standard.

These filesystem vagaries suggest that a pathname might be better
represented as being comprised of types composed at compile time.  That is,

    template <typename Volume, typename Path, typename Filename>
    class pathname;

Since the three types must be managed as a single entity to represent a
single filesystem, we might merge them into a single policy class, but the
concepts remain.  The big question this leaves is whether there is any
meaningful functionality left for "pathname" itself.

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