"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
00aa01c2c791$7df10cd0$1d00a8c0@pdimov2">news:00aa01c2c791$7df10cd0$1d00a8c0@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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
