|
Boost : |
From: Dave Abrahams (abrahams_at_[hidden])
Date: 1999-07-15 21:07:20
> Number 2 is what draws me to Kevlins idea. At the moment shred_ptr has
> a blanket assumption that delete p; is the correct thing to do. And of
> course for the idiomatic use it is. But perhaps there is some merit in
> viewing the decision about what to do if the resource acquisition fails
> as being a client-side decision.
> For example...
>
> widget * p = new widget(...);
> shared_ptr<widget> sp(p);
>
> If the bad_alloc exception comes out of the shared_ptr c'tor p will be
> dangling.
Sure, but then who's managing the widget it points to? If an exception is
thrown, what do you plan to do with p in a catch handler other than delete
it (hint: p is out of scope in the catch handler anyway)?
Anyway, the example seems somewhat contrived. I can make p dangle with any
constructor semantics by making a small change.
widget * p = new widget(...);
{
shared_ptr<widget> sp(p);
}
Now p is dangling if no exception is thrown even if you take Kevlin's
suggestion.
>It's because new long(1) can throw an exception the
> shared_ptr is _forced_ into assuming responsibility for doing the
> delete and it is no longer a client side decision.
Arbitrary flexibility is a drag. You have to prove that the ability to make
the decision could be useful to the client, and is worth the trouble of
*having* to make the decision.
-Dave
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk