Frank Mori Hess:
On Tuesday 29 April 2008 13:03 pm, Peter Dimov wrote:
We need to flesh out the specifications of the changes we are proposing.
One effect sp_accept_owner (and shared_from_this in constructors) have on the > existing specifications is they put a big asterisk on the postconditions of some of the shared_ptr constructors. Really, all bets are off postcondition wise after sp_accept_owner has been called, unless restrictions are placed on what sp_accept_owner is allowed to do. Specifying that sp_accept_owner cannot modify its shared_ptr argument, as you suggested earlier, would allow some postconditions to be preserved, although not the ones involving "use_count() == 1".
This is a very good point, probably even a showstopper for an eventual sp_accept_owner proposal. I note that creating a long-lived shared_ptr in the constructor breaks the postcondition as well. Annoying. In principle, a new esft may avoid this by: 1. Allowing only (expired) weak_ptr instances to be created in the constructor; 2. Bringing the weak_ptr instances back to life once a shared_ptr takes ownership. This however seems to require a relatively major surgery to sp_counted_base and friends; I'm not sure I'm comfortable with that.