Re: [boost] [smart_ptr] questions about some regression test cases

From: Daniel Frey (d.frey_at_[hidden])
Date: 2008-04-29 01:45:53

On Mon, 2008-04-28 at 22:24 -0400, Frank Mori Hess wrote:
> On Monday 28 April 2008 13:38, Daniel Frey wrote:
> > I hope it's OK if we discuss it now. So far, I was under the impression
> > that calling shared_from_this() requires that some other shared_ptr
> > takes ownership later. BOOST_ASSERT( _shared_count.empty() ) tests
> > exactly that. It's an easy to understand rule and I can see the use
> > cases.
> >
> > How would you describe/document the behavior you had in mind? What use
> > case would it serve?
> 
> It asserts that no dangling shared_ptrs exist, or that a shared_ptr has 
> taken ownership (in which case it is assumed the user knows what they are 
> doing).  It permits, for example, weak_ptrs to exist which might be used 
> to track the object's lifetime whether or not it is actually managed by a 
> shared_ptr.  To be more concrete, you might have an object which uses Qt 
> signals/slots and whose lifetime is managed by the Qt framework.  You 
> could use shared_from_this() to get a weak_ptr that can be used to track 
> the object's lifetime by thread_safe_signals, for automatic connection 
> management of additional signals/slots from thread_safe_signals.  It would 
> work equivalently to boost::trackable from the current boost.signals.

OK, thanks.

> On the other hand, I can't think of any situation where aborting on the "no 
> owner and no dangling shared_ptr" case would actually provide any 
> additional safety over allowing it.

Well, the failing test cases are an example - it just depends on whether
you want to allow them or if you consider this usage pattern an error.

Please don't get me wrong, I'm not against it. I am just trying to
clarify the intentions of the code. And I took the freedom to fix the
comment that IMHO was misleading me to think that the test cases were
unintentionally passing.

It also means that sp_deleter_wrapper needs to make sure that it is a
no-op when set_deleter has never been called, which I have to keep in
mind when I try to optimize this stuff further.

Thanks for clarifying.

Regards, Daniel