[boost] Re: Re: Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue

From: David B. Held (dheld_at_[hidden])
Date: 2003-01-29 12:10:53

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:00aa01c2c791$7df10cd0$1d00a8c0_at_pdimov2...
> [...]
> To be honest, I don't know. The design is quite complicated, and I
> don't have the time to study it in-depth. I'm not sure how this interacts
> with stored_type being a smart pointer that owns the object.

Hmm...that's also an interesting point, since one of design rationales was
to make it possible to implement a SmartPtr in terms of a SmartPtr.

> See also:
>
>         friend inline void release(this_type& sp, stored_type& p)
>         {
>             checking_policy::on_release(storage_policy::storage());
>             p = get_impl_ref(sp);
>             get_impl_ref(sp) = storage_policy::default_value();
>             ownership_policy& op = sp;
>             op = ownership_policy();
>         }
>
> I'm not sure whether this works as intended if ownership_policy()
> throws.

Also a good point.  I should document that
storage_policy::default_value() must be no-throw to get the basic
guarantee from release().  That is probably more advisable than trying
to make it safe for default_value() to throw.  In fact, this code is not
correct at all, given the current definition of ref_counted.  In particular,
ref_counted does not define an operator=, which means that the old
count is leaked.  Since the default c'tor allocates a new count, it
could most certainly throw.  It seems wasteful to delete then new
the count.  Perhaps ref_counted should have a reset() function for
this case.  Then we could mandate that it be no-throw (which seems
reasonable).

> [...]
> How often do people write pointers that use the auto_ptr_ref trick?

Ok, not very often.

Dave