From: Philip Nash (philip.nash_at_[hidden])
Date: 2001-07-25 11:02:11
> 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?
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
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)...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk