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,
> >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
> 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
> >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
> 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
> 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
> 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?
> >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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk