[boost] Re: Misc library documentation issues

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

 <199907160203.waa0101-_at_[hidden]> wrote: 
original article:http://www.egroups.com/group/boost/?start=370
> > 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)?

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
of
> *having* to make the decision.

Agreed. That's why I think it's a close call...

Cheers
JJ

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications