Actually, I've realized there's no reason it has to be tied so closely to enable_shared_from_this. There could be a completely independent base class called boost::postconstructible which is treated similarly to enable_shared_from_this in shared_ptr.hpp. Similarly, there could be a boost::predestructible base class that gets its hook called before the shared_ptr deletes its pointer (perhaps only in the default deleter). I believe the hooks would compile to nothing if the shared_ptr isn't holding a pointer derived from one of these classes, just like (I assume) they do for enable_shared_from_this.

...

I think you're better off writing a specialized smart pointer if you want that kind of functionality.

I'm no so keen on a specialized smart pointer, for reasons that you've already brought up earlier. But I suppose that's what I'll do if it comes to it. It shouldn't be too bad to come up with a new name and do a search and replace on shared_ptr.hpp.

My point is, enable_shared_from_this was deemed important enough for special hooks to be put into shared_ptr.hpp for it. So there is precedent. And postconstructors/predestructors aren't peculiar ideas that I just came up with myself. I'm sure they could be useful in other contexts.

Now I realize I don't need any changes to shared_ptr at all, I can do it all in a wrapper function inserted between the raw pointer and shared_ptr. I can't think of a name, so call it ptr_wrapper(): shared_ptr<MyClass>(signalslib::ptr_wrapper(new MyClass)); ptr_wrapper would call postconstruct() if its input pointer is derived from postconstructible, and return a shared_ptr. The deleter for the returned shared pointer would be (by default) customized to call the predestructor if the input pointer is derived from predestructible. A custom deleter could be accepted as a second argument to ptr_wrapper. -- Frank