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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-10 12:07:00

At 06:22 PM 3/5/2002, dylan_nicholson wrote:

 >But "Current working directory" is not really a global variable, it's
 >an operating system concept, just as "active window", "currently
 >logged in user" etc. are.

Because it is known to the operating system doesn't make it less of a 
global variable.  It can still change very unexpectedly.

 >While I agree it's generally better to write code that uses absolute
 >paths

There is nothing wrong with relative paths as long as the point in the 
directory tree they are relative to isn't a global variable.

 > where possible (mainly because using the wd is not thread-
 >safe), you can't always avoid needing to know it.
 >For one thing certain third party libraries either a) silently change
 >the working directory or b) require it to be set correctly to work.
 >A good example of a) is the Win32 ::GetOpenFileName call that
 >displays a dialog box allowing you to choose a file.  By default it
 >changes the working directory, so that the next time you call it
 >starts up in the same directory.  If absolute(...) didn't make use of
 >the correct current directory (as opposed to the initial working
 >directory when the application started), then code like:
 >
 >OPENFILENAME ofn;
 >/* fill in ofn structure */
 >::GetOpenFileName(ofn);
 >name = absolute(ofn.lpstrFileTitle);
 >
 >would unexpectedly not work (I don't want to use GetFullPathName,
 >because it is a pain to call).
 >
 >I have seen examples of b) that are inhouse legacy libraries that for
 >one reason or another are too hard to change.  So for these
 >situations I need to be able to set the working directory.

Sure, and that's exactly why a high quality library won't depend on the 
current working directory; it may change unexpectedly.

 >I really don't see what going out of your way to "ban" users from
 >accessing this is supposed to achieve.

As programs grow, age, or are ported, global variables (particularly 
variables like "current working directory" used by the Windowing system) 
are virtually guaranteed to introduce hard-to-detect bugs. It is as simple 
as that.

Remember that the bug may be introduced by a new version of Windows or some 
other third-party library.  Global variables should be avoided like the 
plauge.

 >Btw no-one has yet answered my concerned about supporting passing
 >char* and wchar_t* strings to file system functions.

Jan and I have char* and wchar_t* overloads in the actual code we have been 
working on.

--Beman