RE: [boost] smart_ptr.hpp refactoring proposal

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
generic class(es)?

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)...

[)o
IhIL..