Re: [boost] [smart_ptr] enable_shared_from_this_light

From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-04-12 22:22:46

Daniel Frey:
> I agree that the implementation should not drive the interface, but I
> still fail to see why passing the deleter should be needed anyway. It's
> not even used in the current enable_shared_from_this implementation, so
> why do you think that it should be part of sp_accept_owner's interface?

One of your earlier posts contained an example "observer" called 
shared_ptr_debugger. You didn't show it doing anything, but I can easily 
imagine it either logging all sp_accept_owner calls, in which case 
typeid(D).name() could come in handy, or checking whether sp_accept_owner is 
called twice on the same object. In the latter case, you do want to 
distinguish between deleterless and deleterful calls, because the same 
object can legitimately be owned by several shared_ptr instances with null 
(or effectively null) deleters.

The change to the esft base demonstrates another use case, one in which the 
object wishes to recognize a particular deleter and do something different 
in sp_accept_owner. It's true that in this particular instance there is 
another way to achieve the desired "do nothing" behavior.

I could however imagine scenarios in which sp_accept_owner and a deleter are 
used as a pair to achieve postconstructor and predestructor behavior. If the 
postconstructor action can fail, sp_accept_owner could indicate this by not 
setting the appropriate "perform predestructor action" flag inside the 
deleter.

We'll see.