Boost logo

Boost :

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,
> >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
> 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
> >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
> >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
> and restore the state involved - that amounts to turning a variable
into a
> constant. Or write code that assumes the global variable changes
> 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
> current working directory.
> So far, the little bit of programming I've done using
> 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
> 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
> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at