Re: [boost] shared_ptr_updates.zip

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-26 08:09:40

From: "Philip Nash" <philip.nash_at_[hidden]>
> Agreed. Sorry, I wasn't suggesting that the finalizer function be dropped
> from your proposal,

There's nothing wrong with suggesting that. I am not entirely convinced that
adding this finalizer support to shared_ptr is a good idea. I simply
demonstrated that it can be done; this doesn't mean that it must be done.

> just that getting into the IiRA idiom's is probably
> beyond the scope of shared_ptr without bloating it (which you seem to
agree
> with from the above).

Actually neither shared_resource nor shared_ptr implements the RAII idiom.
(auto_ptr doesn't either.)

The RAII idiom, when followed, _enforces_ the basic exception safety
guarantee; anything that acquires resources outside a constructor does not:

f(shared_ptr<int>(new int), shared_ptr<int>(new int)); // may leak

shared_resource would have the same problem.

I'm not saying that shared_resource is not useful; it would probably work
well as a building block. The danger is that when it's there people will use
it in unsafe ways.

Generalizing a tool has its pros and cons; it becomes useful in a wider
variety of situations, but at the same time it becomes less specialized.

For instance, shared_ptr is very similar to shared_array but not quite the
same; it has operator*, operator-> and dynamic_cast, whereas shared_array
has operator[].

A good library may use shared_* internally but will not expose them to the
user; it will provide a custom 'handle' class that is tailored to the exact
semantics of the managed resource.

> How are you implementing the finalizer, btw? Does it allow for member
> functions (useful for obj->Release() style deletions)?

std::mem_fun or

http://www.mmltd.net/pdimov/mem_fun.html

will take care of this.

--
Peter Dimov
Multi Media Ltd.