Boost logo

Boost :

From: Jason Stewart (res0054p_at_[hidden])
Date: 2002-01-30 08:45:57

At 09:59 AM 1/30/2002 +0000, you wrote:
>From: "Stewart, Robert" <stewart_at_[hidden]>
> >
> > If you're using the Unix/Windows pathname manipulation class, then
> > is quite appropriate. If you're using the Mac OS X
> > pathname manipulation class, then you wouldn't supply at
> > all, from my understanding.
>I think we need to clarify why anyone would want a library for
>pathname manipulation. If I know that I'm targetting a particular
>OS, then there are probably OS-specific library functions or APIs
>that already do the job. If I'm targetting several OSes, then
>I can either use conditional compilation and write the code several
>times, or I use a library that does all that for me.

I know of no cross platform functions for doing this. Microsoft has a
_splitpath function which is painful to use well. An earlier poster stated
that everyone and their pet yak had implemented this functionality. This
implies a general need.

>In the latter case, if I don't supply on the Mac, then
>I won't be supplying it on Unix/Windows either. So what do I supply?
> > This isn't the responsibility of the pathname manipulation class.
>As I said earlier, manipulating paths is pointless unless the
>resulting paths can be used. That means thinking about how those
>paths are eventually used to create or open files of an appropriate
>type (for those systems that care) for third party apps and with
>"culturally correct" names for the end user.

Again, you are talking about writing data. Tell me how to write the
resource fork for a "foo" file on the Mac there is more to it than just
writing ".foo" to a file.

If I were to specify a file called "" then it is just as valid on
the Mac as it is on the PC. It does not matter what type the file is. As
far as not allowing extensions on a Mac (or any other platform that does
not tend to use them), this seems like a harsh policy to enforce. What if
the user really wants to use a period in their filename? You mentioned
allowing the user to specify an extension but not the application, but for
a library, the application is the user. Given the filename "" did
it come from the user or from the application? I'm all for
"multiculturalism". I just don't think a library should enforce culture.

>Remember, we already have OS-specific solutions for manipulating
>paths. I wouldn't personally be interested in another one. I would
>be interested in a cross-platform way of storing, mutating and
>using "file system thingies". I'm happy to accept that a path
>parser would be part of that, and that the hard part is done
>elsewhere, but if the hard part can't be done then there is little
>point in providing the parser.

No one has talked about writing an OS specific class. We have talked about
policies that know how to interpret OS specific paths but the system should
be cross-platform.

I think I understand the Mac's FSRefs a little better now. But they refer
to specific files. The point of this class was to provide manipulation of
filenames/pathnames in an abstract way without using the filesystem. Maybe
there is some common functionality that can be factored into a higher level
class though. This needs more input from some of the Mac people on the list
though, I don't have access to a Mac and haven't used one is a decade. I am
interested in this aspect though.


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