Boost logo

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

>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.


------------------------------------------------------------------------ home: - Simplifying group communications

Boost list run by bdawes at, gregod at, cpdaniel at, john at