From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-15 15:35:24
At 04:50 PM 3/14/2002, dylan_nicholson wrote:
>> >Then why are you singling out current directory as something
>> >programmers shouldn't be able to access/change easily?
>>
>> Because that's the library I'm working on.
>
>But the library you're working on *does* allow you to determine the
>existence/properties of a file. That is actually far more likely to
>change "unexpectedly" than the current directory - at least the
>current directory can't be changed by anything else other than the
>current process.
Yes, that's a serious problem. It is one of the reasons to be so picky
about specifying the error conditions which can cause exceptions to be
thrown.
>I like the push/pop idea. But I gave an example earlier (using
>Win32's GetOpenFileName) where you need to determine what the current
>directory has been changed to by a library call.
If we come up with portable programs that need a feature that can added in
a portable manner, I'll give it serious consideration. But if the need is
solely to interface with a platform specific function like GetOpenFileName,
just use the platform specific GetCurrentDirectory.
>> Questions about your example above:
>>
>> What is the expectation for portability if the O/S has only a flat
>(single
>> directory) file system?
>>
>Just the same as if the O/S had no filesystem :o)
One of my design targets is a system (perhaps a small embedded system)
which has a flat (single directory) file system. I'd like as much as
possible of a filesystem library to work in that environment.
>>What is the expectation for portability if the O/S supports
>>hierarchical directories, but has no concept of "current directory"?
>>
>
>Any OS-interfacing library has essentially an platform-dependent
>implementation. If such a platform really did exist then even
>fstream::open/fopen etc would need a method of telling the OS how to
>open an incompletely specified filename, meaning the standard C
>runtime library would probably have to maintain the current
>directory. But I think you're genuinely clutching at straws here - I
>would be intrigued indeed if you really know of such an OS.
That's a good question. I'm having trouble finding out about some of the
big mainframe systems like OS/390. Even if some of those monster systems
(which often run numerous O/S's in different virtual machines) still run
older O/S, does anyone write new programs for them in C++? Does anyone
reading this know?
>It kinda seems that from other posts on this subject you are somewhat
>alone in wanting to keep the current directory away from the
>programmer's reach - I understand your concerns but in the end the
>library has to be useful in the "real world" as it were.
I'll add it (directly or indirectly) when and if someone comes up with an
example of a ("real world" or not) portable problem that is poorly handled
(or not handled at all) by a design that doesn't rely on get/set current
directory.
--Beman