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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk