Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-03-20 12:58:53

From: "Beman Dawes" <bdawes_at_[hidden]>
> >What is the purpose of initial_directory() if it doesn't affect relative
> >paths?
> Let's say a user provides a relative path to a directory your program is
> supposed to operate on. (Presumably your program can tell this from one
> the filesystem/path.hpp functions.)
> (Assume you told the user relative paths were relative to the current
> working directory at time of program invocation. Otherwise the issue of
> current or initial directory wouldn't come up because other scenarios know
> what the relative path is relative to.)
> Now you could just pass that relative path to some boost::filesystem
> function, and it might work just fine. But it might not work exactly as
> expected. Some other 3rd party or native system library function may have
> changed the current working directory unexpectedly.
> So code something like this is a lot safer:
> int main( int argc, char * argv[]
> {
> initial_directory(); // lock down before calling other functions
> string dir_path;
> if ( user provided a relative path )
> dir_path = compose( initial_directory(), user provided path );
> else
> dir_path = user provided path;

IOW a make_absolute() function, if provided, would treat relative paths as
relative to the initial_directory(). Yes, I see.

How is this superior to simply providing a getcwd() function and letting the
user do

int main()
  std::string initial = getcwd();
// rest unchanged


> >basic_directory_iterator probably doesn't need a destructor.
> Depends on how the internals are implemented, doesn't it? If the rep type
> is opaque and non-trivial (as in the current imp) then a destructor is
> needed, for example.

Well, it uses shared_ptr, and its destructor does the right thing for
incomplete types. :-)

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