Boost logo

Boost :

From: Jason Stewart (res0054p_at_[hidden])
Date: 2002-01-28 08:56:18

>Aren't paths an implementation detail? What about OS's now and in the
>future that deprecate paths? I don't see why we can't create a higher
>level class that works just as well as a path-centric class, but also
>works well on the Mac OS.

I'm a little unclear on this. Admittedly, I haven't used a Mac since '89 or
so (not because I don't like them, simply not in my job description), and
its been even longer since I used a Vax. But there have been several
references to paths being deprecated on the Mac. I don't completely
understand what you use instead. I saw a reference to FSRefs and searched
on the web. As far as I can tell it is an opaque data type used to identify
a file. It seems to me that somehow the user must be able to specify a
"path" to a file in any hierarchical filesystem. The user cannot be
expected to specify the inode.

I went to Apple's website and did a little research (only about 5 minutes
worth so I could have easily missed a lot). There, I see several references
to path names, hierarchical filesystems,directories, etc. An example from
one of their pages:
/Mac OS X/

The looks like you could easily specify a path as "/Mac OS
X/Users/Steve/Documents/" to find a file located in Steve's documents
directory. To me, it still looks like it would be useful to have a class
that manipulates theses paths. You might want to iterate through the pieces
that make up this path, or get the root volume, or change the last
directory entry, etc. The main point of this class is manipulation of the
pathname strings, not actually file manipulation. I think that is a
different problem.

I freely admit my ignorance here so please help me understand what level
you are talking about.


Boost list run by bdawes at, gregod at, cpdaniel at, john at