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
> 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
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)?
will take care of this.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk