Re: [boost] Mac OS and paths

From: Darin Adler (darin_at_[hidden])
Date: 2002-01-28 13:24:56

On 1/28/02 10:08 AM, "David Abrahams" <david.abrahams_at_[hidden]> wrote:

> The question is, are the set of operations similar enough that it makes
> sense to try to represent FSSpecs with the same cross-platform class as
> paths?

It's hard to say. We'd have to talk about the individual operations.

For example, getting the path of the parent can be done with an FSRef, but
only for an actual file that exists, and it requires a system call. With a
Unix-style string path, you can get the path of the parent even if the path
is for a non-existent file, without making a system call.

> If someone has a program written to manipulate paths on Unix will
> they be able to apply the same operations on MacOS 9?

There are certainly subsets of operations that overlap. Certainly the
Macintosh file system API does all the same sorts of things with these that
you would do with paths on Unix. Like opening files, moving files, finding
files in a directory, creating files.

> It might make sense to
> manipulate paths on the Mac with this class, since after all they do exist.

Good point.

> I am an old Mac guy, but too old I guess: I've forgotten. BTW, does this
> apply to OS X?

Yes and no. There are at least two styles of paths in OS X: The old Mac OS
style paths still have the same flaw they did before OS X -- they don't work
if there are two volumes with the same name. Then there are the POSIX paths,
which don't have that problem.

It's probably useful to remember that this discussion began because we were
talking about generalizing a cross-platform "iterate all the files in this
directory" function. It makes complete sense to implement that for
additional platforms.

But it's misleading to talk about platforms that don't have path names. Any
platform that supports standard C must support a string-based file naming
scheme of some sort. These are the strings you pass to fopen or
basic_fstream::open calls. Whether we call them "path names" or "file names"
or whatever, supporting more operations on those strings makes sense to me.

    -- Darin