Boost logo

Boost :

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

Ivan Sorokin <vanyacpp <at>> 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.

RAIIWrapper<RAIIDeleter(fclose)> pFile = fopen(...);

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

-Andrew Sandoval

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