On Tuesday 06 February 2007 17:48 pm, Timmo Stange wrote:
Frank Mori Hess wrote:
Okay, here's the partial-template-specialization proof of concept, where polymorphism is confined to a specialization of enable_shared_from_this.
It's a partial template specialization and not all compilers support that well enough. I know that you can work around this and I don't want to be a spoilsport, but I think this is a too intrusive approach for the limited purpose it satisfies. What about exception safety regarding the call to postconstruct, for example? What if a derived class implements postconstruct for its own purposes and doesn't forward it up the class hierarchy? Wouldn't you need a predestruct for this to be usable for more than your specific needs?
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. -- Frank