
Frank Mori Hess wrote:
On Tuesday 17 February 2009, Nat Goodspeed wrote:
I can in fact detect a bound shared_ptr and pass it to track() as I want. The problem is that binding a shared_ptr captures a copy, so the referenced object will live until the connection is explicitly disconnected! That makes the slot_type::track() mechanism moot.
It looks as though I could only achieve what I want if my visit_each() visitor could *modify* the boost::bind object to replace the bound shared_ptr with its wrapped plain pointer. I don't believe this is possible?
Wouldn't it be better just to make your visitor just detect a bound shared_ptr to Trackable and report it, forcing the calling code to get it right? You could use BOOST_STATIC_ASSERT to give a compile-time error, for example.
I'm sorry, I didn't express myself clearly. There are actually several different cases: 1. visitor discovers plain pointer/reference to a subclass of my Trackable base class: Use Trackable to track the new connection. This is working now -- but as you point out, it's less safe than your slot_type::track() mechanism since a Trackable might be destroyed during a slot call. 2. visitor discovers a shared_ptr to something other than a Trackable subclass: This is the case I was asking about. My visitor can in fact pass the shared_ptr to slot_type::track(), but it's pointless because the shared_ptr copy stored in the boost::bind() result makes the referenced object effectively immortal. To my surprise, I find that it's not destroyed even when I explicitly disconnect the resulting connection. 3. visitor discovers a weak_ptr to something other than a Trackable subclass: Though I had to specialize boost::get_pointer() for weak_ptr myself, with that in place, this case works now. My problem is that I can't imagine every coder consistently remembering to convert a shared_ptr to weak_ptr before passing it to boost::bind(). 4. visitor discovers a shared_ptr to a Trackable subclass: This is the case you mention above. To tell you the truth, though, this doesn't look like an error to me. In effect, I have a choice between two different connection-management mechanisms. Given that slot_type::track() is safer than my Trackable mechanism, I'd prefer to use that -- but unless we can somehow create a new boost::bind object that omits the bound shared_ptr, it's moot. 5. visitor discovers a weak_ptr to a Trackable subclass: I currently use the slot_type::track() mechanism for this case too. In other words, once the visitor discovers a shared_ptr or weak_ptr, it stops caring about the pointee type.