Re: [boost] smart_ptr.hpp refactoring proposal

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-07-25 12:11:38

From: Philip Nash <philip.nash_at_[hidden]>
> > From: Peter Dimov <pdimov_at_[hidden]>
> 
> > One is to allow for the user to specify a delete function or function
> > object at construction time,  e.g.
> >
> >     shared_ptr<FILE> file_ptr(fopen(file_name,file_mode),fclose);
> >
> > I think that now with boost::function this is a small step from
> > what you have already with your shared_deleter.
> 
> I wrote something very similar to this, although not with ref counted smart
> pointers (and using my own generalised functor classes - before function was
> added to boost).
> In my case I use it to call release() methods on objects that you should not
> call delete on (such as COM objects, for example, although this is not what
> I used it for).
> 
> That makes it useful for (third party) intrusive rc classes, or for non rc
> classes that, say, are allocated on a heap you don't have access too (such
> as in a dll in windows).
> 
> So perhaps there is a case for this extension to scoped_ptr too? Thoughts?

Yes, there is.

> WRT to the example you give above for your proposal perhaps it should be
> made more explicit that this is a true "initialisation is resource
> aquisition" idiom (I know that, technically the existing smart_ptr classes
> are IiRA), perhaps by calling it resource_ptr (or scoped_resource_ptr and
> shared_resource_ptr)... or is that going a bit far?
>
> Obviously using FILE pointers is contrived for the sake of an example, but
> an "IiRA" object is such a widely used idiom perhaps it deserves its own
> generic class(es)?

Not that contrived -- I still like FILE where iostreams is overkill, and
lots of other C libraries return pointers to some struct that has to be
released by some function.  So I do want for shared_ptr to support user
specified release.  It is also a frequently requested feature for use in
shared libraries, COM-style interface, and more.

> If we do that, we could even remove the restriction that the "contained"
> object be a pointer at all! We could then use it to aquire and release
> opaque handles using naive functions (as with the fopen, fclose example)...

Since shared_ptr<T> automatically declares T* I don't think it can be
generalized to non-pointer types.  But a separate scoped_resource and
shared_resource facility would be a useful addition to boost.