Re: Design for a file system library

From: dylan_nicholson (dylan_nicholson_at_[hidden])
Date: 2002-03-10 20:50:54

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> 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.
> 
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?  

>  >
>  >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.
> 
Agreed, but most libraries *aren't* high quality and boost doesn't 
exist in a void.

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

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

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

Dylan