From: dylan_nicholson (dylan_nicholson_at_[hidden])
Date: 2002-03-12 16:45:26
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 06:01 PM 3/11/2002, dylan_nicholson wrote:
> >Currently logged-in user is not constant under most modern OS's,
nor
> >is active window, nor is the environment, nor is current
> >directory...etc. etc.
> >And why is the existence (or indeed the contents) of a file
an "ok"
> >global variable to access/modify, but current directory not?
>
> None of those are "OK". They are all dangerous in proportion to
the
> likelihood that they change unexpectedly.
>
Then why are you singling out current directory as something
programmers shouldn't be able to access/change easily?
> >> And the global state issues are well-know; Boost just added a
new
> >library
> >> to help deal with that problem.
> >>
> >Which library is that?
>
> Daryle Walker's I/O state saving library.
>
But how does that relate to cout/cerr/cin being global? The issue of
state permanence applies to all streams, even ones that you do
carefully pass around everywhere as needed.
> >Are you suggesting that *ALL* this information should be passed to
> >every function that might ever need it (including obviously
functions
> >that don't need it directly, but make use of others that do).
>
> Of course not. Provide a function that returns a constant value. Or
save
> and restore the state involved - that amounts to turning a variable
into a
> constant. Or write code that assumes the global variable changes
value
> between accesses. Sometimes it is harder, sometimes easier.
>
Ok then we are in complete agreement. But you haven't explained
why "current directory" shouldn't be the sort of global data that
needs controlled/careful access as opposed to no access.
> But the real issue isn't global variables in general, it is
setting/getting
> current working directory.
>
> So far, the little bit of programming I've done using
initial_directory()
> rather than current_directory() has gone smoothly. That's the
proof of the
> pudding. Is the code better or worse because it doesn't set/get
current
> directory. So far, it seems easier to write, to read, and more
> robust. It was easier because it didn't require keeping a mental
image of
> where in the directory tree "current" was. The variable names were
more
> indicative. But far more test cases are needed.
>
Indeed. Just yesterday I wrote a simple utility using nothing but
standard C++ and a few filesystem calls. And guess what - it needed
to change and restore the working directory because it executed
another application (using system), which had to be run in a
particular directory to work correctly.
Dylan