Boost logo

Boost :

From: Ken Hagan (k.hagan_at_[hidden])
Date: 2002-01-30 04:59:47


From: "Stewart, Robert" <stewart_at_[hidden]>
>
> If you're using the Unix/Windows pathname manipulation class, then
> myfile.foo is quite appropriate. If you're using the Mac OS X
> pathname manipulation class, then you wouldn't supply myfile.foo 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.

In the latter case, if I don't supply myfile.foo 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.

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk