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.
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk