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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-11 14:15:13

At 08:50 PM 3/10/2002, dylan_nicholson wrote:

 >> global variable.  It can still change very unexpectedly.
 >>
 >So can the existence of the file "c:\test.txt" - that's just as much
 >as a "global variable" by your definition.  More accurately "working
 >directory" is a property of the current process.  Nearly every OS
 >call you make makes use of a whole host of properties like this.  How
 >is current directory different to currently logged-in user etc. etc?

Many of those O/S properties are constants, not variables, so don't present 
the same set of problems.  The existence of a file (and even whether it is 
a file or directory, since that may change unexpectedly too) is in effect a 
global variable; that's why error handling is so important in this and 
other I/O related libraries.

 >> 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.
 >>
 >It's simple to say that, but you haven't provided much in the way of
 >evidence.

It isn't just me that is saying "global variables considered harmful."  It 
is the whole software engineering establishment. Wulf and Shaw's paper of 
that name is considered one of the great papers in computer science.  See 
http://bit.csc.lsu.edu/~chen/GreatPapers.html

 >> 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.
 >>
 >Just like typos and cliches :o)  I'm not sure what you define as a
 >Global variable.  Global data is essential in most large scale
 >applications and libraries, provided it's managed sensibly (ie no
 >direct access).  If you literally had to pass all the information you
 >ever needed around as function parameters I would give up programming
 >tomorrow.
 >Btw have you ever used cin, cout or cerr?

And the global state issues are well-know; Boost just added a new library 
to help deal with that problem.

If you've always designed with global variables, the first few designs 
without them are a bit difficult.  But once you get used to avoiding this 
source of problems, it gets really easy.  And the designs become 
considerably more robust.

 >>  >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.
 >>
 >Ok good, just wanted to be sure.

It is a bit messier that it looks; I'm about to post some code for comment 
to make sure others agree with the approach I'll suggest.

--Beman