Boost logo

Boost :

From: jon.jagger_at_[hidden]
Date: 1999-07-16 04:52:48

 <199907160203.waa0101-_at_[hidden]> wrote:
original article:
> > 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
exception is
> 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
with any
> constructor semantics by making a small change.

Sure sure. I'm not arguing for Kevlins idea violently. I think its a
close call.

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

Yes but with kevlins suggestion you could write...

widget * p = new widget(...);
shared_ptr<widget> sp(p);
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
to make
> 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...


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

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