Date: 1999-07-16 04:52:48
> > Number 2 is what draws me to Kevlins idea. At the moment shred_ptr
> > a blanket assumption that delete p; is the correct thing to do. And
> > course for the idiomatic use it is. But perhaps there is some merit
> > viewing the decision about what to do if the resource acquisition
> > 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
> > dangling.
> Sure, but then who's managing the widget it points to? If an
> thrown, what do you plan to do with p in a catch handler other than
> it (hint: p is out of scope in the catch handler anyway)?
I agree. It's entirely likely that the client is going to want to
delete p; But are they always going to want to? Now and forever?
> Anyway, the example seems somewhat contrived. I can make p dangle
> constructor semantics by making a small change.
Sure sure. I'm not arguing for Kevlins idea violently. I think its a
> widget * p = new widget(...);
> shared_ptr<widget> sp(p);
> Now p is dangling if no exception is thrown even if you take Kevlin's
Yes but with kevlins suggestion you could write...
widget * p = new widget(...);
p = 0;
but hey, lets not get into a contrived-code competition ;-) You'll win
> >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
> the decision could be useful to the client, and is worth the trouble
> *having* to make the decision.
Agreed. That's why I think it's a close call...
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