Re: [boost] smart_ptr vs smart_resource

From: Sam Partington (Sam.Partington_at_[hidden])
Date: 2003-02-20 12:26:37

David Abrahams wrote:
> "Phil Nash" <phil.nash.lists_at_[hidden]> writes:
>
>>     Pointers are Resources
>>     Resources are not (all) Pointers.
>
> Actually,
>
>       Pointers *refer to* resources
>       Not all pointers refer to (are) resources

I like word games:

Not all resources are referred to using pointers.

I like the idea of changing smart_ptr to smart_resource, or smart_handle.

Now that I think about it I have never used a PBSP to actually store a
"pointed to resource".  I always to use them to store non-pointer based
resources, like socket handles, or registry key handles.  If I have a
"pointed to resource" it always goes into a shared_ptr.

Something I've been doing lately:

template<class T, void (*f)(T)> struct resource_deleter
{
 void operator()(T* t)
 {
  if (t)
   f(*t);
  delete t;
 }
};

int get_int_based_resource() { return 0;}
void release_int_based_resource(int) {}

void f()
{
 boost::shared_ptr<int> resource(new int(get_int_based_resource()),
resource_deleter<int, release_int_based_resource>());

// do something with the resouce

}

Essentially using shared_ptr as a scope guard.  Of course what is stupid
about this method is the new and delete are totally unnecessary, and are
only there  Obviously this is not an ideal solution, (at least) two better
solutions are available:

1) use a shared_resource<>, where there is no requirement to pass a T*. (But
there is no public one at the moment)
2) a PBSP, but using a policy based smart pointer seems no clearer to me
than doing what I've done above.  (although it would remove the unnecessary
allocations).

So I find myself doing the above. (actually it is abstracted away in a
wrapper)

Anyway, my point is:  I'd be very much in favour of shared_resource OR
renaming smart_ptr to smart_resource.  (where the PBSP is demphasised from
being smart pointer, to a general smart resource handler)

Sam