Re: [boost] Proposed new RAII Library

Subject: Re: [boost] Proposed new RAII Library
From: Andrew Sandoval (sandoval_at_[hidden])
Date: 2012-09-14 17:25:44

Ivan Sorokin <vanyacpp <at> gmail.com> writes:

> 
> On 12.09.2012 05:40, Andrew Sandoval wrote:
> 
> > The first of these is RAIIFunction (I'm open to other names and coding
> > conventions).
> 
> This approach has one problem.
> 
> The typical usage is something like that:
> 
> FILE* f = fopen(...);
> if (!f)
>      return;
> 
> RAIIFunction<void> close_f = [f](){ fclose(f); } // may throw!!!
> 
> The construction of std::function for RAIIFunction may throw 
> std::bad_alloc. In that case you will get leaked file handle.
> 

Yes it could, but that is why I would always use the RAIIWrapper class for
something as simple as fclose.
e.g.:

RAIIWrapper<RAIIDeleter(fclose)> pFile = fopen(...);
if(!pFile.IsValid())
    return;

Because RAIIWrapper doesn't alloc anything, it will construct without risk of
throwing.  And because it has a built-in no-delete value, you don't need to
check for NULL before letting it call fclose.

It's a better solution for most things, but there are cases where RAIIFunction
with a lambda or a function produced by bind are more desirably, and the user
will need to understand the risks -- which in the large major of cases are next
to nil anyway, before they elect to use RAIIFunction.  (I'm not suggesting that
an alloc failure isn't possible, I know it is, and I know that in a library you
can't possibly anticipate all of the possible uses -- I am just suggesting that
we have to deal with that kind of thing all of the time anyway.  I don't know
about you, but I use vector all of the time in place of malloc'd memory, because
of it's RAII features, because it's expandable, etc.  The risks are much the
same.

-Andrew Sandoval