Re: [boost] Re: Design for a file system library

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-03-15 16:06:20

From: "Beman Dawes" <bdawes_at_[hidden]>
> I'll add it (directly or indirectly) when and if someone comes up with an
> example of a ("real world" or not) portable problem that is poorly handled
> (or not handled at all) by a design that doesn't rely on get/set current
> directory.

Your objections do not extend to getcwd(), correct? Many functions
implicitly use the current directory, and I don't see what is gained by not
providing a way to query it. If you supply a make_absolute() function (which
is a good idea) it would be trivial to emulate getcwd() anyway.

About setcwd(). Perhaps a good design shouldn't need to use it.
Unfortunately code often interacts with not-so-well designed third-party
libraries. :-) You'll simply force programmers to use the non-portable
equivalent. POSIX provides one:

"The chdir( ) function shall cause the directory named by the path name
pointed to by the path
argument to become the current working directory; that is, the starting
point for path searches
for path names not beginning with '/'."

You can always ignore setcwd() on a platform without directories.