RE: [boost] Thought on paths

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-30 08:41:00

From:	Ken Hagan [SMTP:k.hagan_at_[hidden]]
> 
> 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

A worthwhile effort.

> OS, then there are probably OS-specific library functions or APIs

Most (all?) such APIs are C-compatible, meaning char *, etc.  Is there a
standard set of APIs for that purpose under Posix?

> 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.

Or, you might use a library that can handle most of the cases and add
conditional logic for those it doesn't.

> 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?

I can't speak from experience WRT the Mac, and I still don't understand how
a Mac program can locate a log file or the directory in which it should puts
an output file, etc.  However, I do know that under Unix-like OSes, I'd
supply a pathname.

> 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.

Certainly, but that doesn't imply that a single class must do all of that
work for all operating systems and filesystems in use.

> Remember, we already have OS-specific solutions for manipulating
> paths. I wouldn't personally be interested in another one. I would

Are there such solutions for all combinations of OS and filesystem?  Does
the Mac OS provide APIs for manipulating Unix pathnames?  How about the
reverse?  Does Windows provide APIs for manipulating Vax pathnames?  I doubt
it.

Furthermore, those solutions don't interact well with modern C++, so each
would need to be wrapped in a C++ class to improve their usability.

> 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.

From my myopic point of view, having worked only on Unix/Windows/DOS
platforms, the pathname manipulation class we've been discussing would be
terrific.  If there is no meaningful equivalent for Mac OS, as one example,
so be it.  Perhaps there needs to be a different class for manipulating
whatever it is one manipulates on Mac OS, or a mainframe, etc., to specify a
file location.  Then, a filesystem class can support the pathname class, if
appropriate, or the Mac OS class, if appropriate, etc., to locate or create
a filesystem "thingie."

Let's not throw out the baby with the bath water.

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