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
>> variables like "current working directory" used by the Windowing
>> are virtually guaranteed to introduce hard-to-detect bugs. It is as
>> as that.
>It's simple to say that, but you haven't provided much in the way of
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
>> Remember that the bug may be introduced by a new version of Windows
>> other third-party library. Global variables should be avoided like
>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
>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
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk