Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-28 09:19:44


From: "Philip Nash" <philip.nash_at_[hidden]>
> > From: Peter Dimov [mailto:pdimov_at_[hidden]]
>
> > The RAII idiom, when followed, _enforces_ the basic exception safety
> > guarantee; anything that acquires resources outside a constructor
> > does not:
>
> One possible way of making it true IIRA/RAII (choose your prefered
ordering)
> then, would be to move the initialiser function by passing that in as a
> functor too.

[...]

> This would allow a syntax like this (using the FILE* example again):
>
> boost::scoped_resource<FILE*>f( boost::initializer( &fopen,
> "my_file.txt", "rt" ), &fclose );

boost::initializer looks very similar to boost::bind to me. :-)

[...]

> This would allow the following syntax:
>
> boost::scoped_resource<FILE*>f( &fopen, &fclose );
>
> f.init( "my_file.txt", "rt" );
>
> ... which seems quite natural.

This is an interesting approach, but you have to consider at what point the
"generic-ness" of scoped_resource becomes a liability rather than an asset:

boost::file f("my_file.txt", "r");

f.read(...);

People have a natural tendency to avoid "unnecessary" work, and when you
hand them a shared_resource that handles anything that moves, they would
never write that boost::file class. And they will refer to shared_resource
as the "modern C++ way of doing things" and will dismiss the dedicated
handle approach as "old school." :-)

> > > How are you implementing the finalizer, btw? Does it allow for member
> > > functions (useful for obj->Release() style deletions)?
> >
> > std::mem_fun or
> >
> > http://www.mmltd.net/pdimov/mem_fun.html
> >
> > will take care of this.
>
> But wouldn't it have to be used internally?

It would if you want to be able to write

shared_ptr<Object>(Object::create(), &Object::release);

but the slightly more elaborate

shared_ptr<Object>(Object::create(), std::mem_fun(&Object::release));

should work with the current version.

--
Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk