From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-04-12 22:22:46
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk