title: Binding a callbacks to an expiring shared_ptr?
body: <p>I am familiar with <code>std::shared_ptr</code> and <code>std::weak_ptr</code> and know how they work. However, I would like the <code>std::shared_ptr</code> to emit a callback, like a boost signal. This would allow <code>std::weak_ptr</code>, who still refer to the deleted object, to be cleaned up right in time.</p>
  
  <p>Is there maybe already some smart pointer implementation, which will report the destruction?</p>
  
  <h2>Explanation</h2>
  
  <p>I think there might be a small design flaw in <code>std::weak_ptr</code>s, that can lead to false memory leaks. By "false memory leak" I mean an object, that is still accessible by the program, but whose reason of existence is not valid anymore. The difference to a true memory leak is, that the true memory leak is completely unknown by the program, while the false leak is just a part that wasn't cleaned up properly.</p>
  
  <p>Another description can be found at <a href="http://www.codingwisdom.com/codingwisdom/2012/09/reference-counted-smart-pointers-are-for-retards.html" rel="nofollow">codingwisdom.com</a></p>
  
  <blockquote>
    <p>Use Watchers</p>
    
    <ol>
    <li><p>One of the problems with freeing an object is that you may have done so while other things are still pointing at it.  This introduces dangling pointers and crashes!  To combat the evil of dangling pointers, I like to use a basic "watcher" system.  This is not unlike the weak reference discussed above.  The implementation is like this:</p></li>
    <li><p>Create a base class "Watchable" that you derive from on objects that should broadcast when they're being deleted.  The Watchable object keeps track of other objects pointing at it.
    Create a "Watcher" smart pointer that, when assigned to, adds itself to the list of objects to be informed when its target goes away.</p></li>
    </ol>
    
    <p>This basic technique will go a long way toward solving dangling pointer issues without sacrificing explicit control over when an object is to be destroyed.</p>
  </blockquote>
  
  <h2>Example</h2>
  
  <p>Let's say we implement the observer pattern using boost <a href="http://www.boost.org/doc/libs/1_58_0/doc/html/signals2.html" rel="nofollow">Boost Signals2</a>. We have a class <code>Observable</code>, that contains one or more signals and another class <code>Observer</code>, that connects to <code>Observable</code>'s  signals.</p>
  
  <p>What would happen to <code>Observable</code>'s slots, when a observing <code>Observer</code> is deleted? When we do nothing, then the connection would point to nowhere and we would probably receive a segmentation fault, when emitting the signal.</p>
  
  <p>To deal with this issue, boost's slots also offer a method <code>track(const weak_ptr&lt;void&gt;&amp; tracked_object)</code>. That means, if I call <code>track</code> and pass a <code>weak_ptr</code> to <code>Observer</code>, then the slot won't be called when the <code>weak_ptr</code> expired. Instead, it will be deleted from the signal.</p>
  
  <p>Where is the problem? Let's we delete an <code>Observer</code> and never call a certain signal of <code>Observable</code> ever again. In this case, the tracked connection will also never be deleted. Next time we emit the signal it will be cleaned up. But we don't emit it. So the connection just stays there and wastes resources.</p>
  
  <p>A solution would be: when owning <code>shared_ptr</code> should emit a signal when it is destroying it's object. This would allow other other objects to clean up right in time. Everything that has a <code>weak_ptr</code> to the deleted object might register a callback and false memory leaks could be avoided.</p>