Re: [boost] boost/filesystem/directory.hpp attached for comment

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
of
> 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. :-)