[boost] Re: Misc library documentation issues

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