Re: [boost] [filesystem] scoped_file feature request?

Subject: Re: [boost] [filesystem] scoped_file feature request?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-10-12 07:18:06

Jorge Lodos Vigil wrote:
> Beman Dawes wrote:
>
> > There is a long outstanding feature request, #1090 from
> > Marcus Lindblom, requesting the following be added to
> > Boost.Filesystem:
>
> > class scoped_file {
> > public:
> >    explicit scoped_file(const boost::filesystem::path& file)
> >      : m_path(file) {}
> >
> >    ~scoped_file() { boost::filesystem::remove(m_path); }
> >
> > private:
> >    boost::filesystem::path m_path;
> > };
>
> > My weakly held opinion is that this request should be
> > rejected.
> > Rationale: Easy enough for users to do themselves, so it
> > doesn't justify the additional surface area it would add to
> > of the library.

It satisfies a not uncommon need.  Boost.ScopeExit can be used to effect the same behavior:

   std::string const pathname(/* get the pathname */);
   BOOST_SCOPE_EXIT((&pathname))
   {
      boost::filesystem::remove(pathname);
   } BOOST_SCOPE_EXIT_END

That's not nearly as satisfying as:

   std::string const pathname(/* get the pathname */);
   boost::filesystem::scoped_file _(pathname);

Alexandrescu's ScopeGuard provides another means to produce the same behavior.

> > Does anyone have a killer argument for adding it?

The obvious use is that one is creating a temporary file in a scope and wishes to ensure that it is deleted upon leaving that scope.  I've done this sort of thing many times.

> If the constructor would create the file I find this useful,
> even more if there is an option to create a unique file (using
> tmpfile, for instance). Temporary unique files are common and
> it would be nice to have a portable implementation. The name
> could be temporary_file instead of scoped_file. Please note
> that the current unique_path function is not very useful
> because the path is unique when it is generated but not
> necessarily when it is used.

I created just such a temporary file class for use in our unit test library.  It uses OS-specific APIs to create a temporary file which it destroys on destruction.  Obviously, such a class must provide normal file operations to be useful, whereas scoped_file is merely concerned with removing the file upon scope exit.

Note that the interface of scoped_file is not as complete as it could be.  Adding a release() member function would mark the file to not be deleted in the destructor.  That would expand the usefulness of scoped_file to cases in which the file may be wanted beyond the current scope, leaving scoped_file to delete it when things fail.  Another useful addition is a remove() member function to delete the file explicitly.  That allows for exception propagation whereas the destructor cannot do so.  (Whether anyone would ever bother calling remove() is another matter.)

> In its current version I think this class is prone to errors.
> Since the destructor removes the file, it might be confusing
> if the constructor creates it or not. The confusion increases
> if file creation  is added to the library.

Many things in C++ are prone to errors.  They can still be useful.  For the intended purpose, I think the real problem with scoped_file is the name.  scoped_file_remover would be clear and avoid any confusion as to its use.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.