Frank Mori Hess:
On Saturday 12 April 2008 12:07 pm, Peter Dimov wrote:
So you suggest we throw your improved implementation away? :-) This doesn't seem right to me, as it represents a fair amount of knowledge that will be lost. Maybe we need to move it somewhere, to boost/smart_ptr/esft_constructor_base.hpp, for instance? And link it from the docs.
Keeping it (and the enable_shared_from_this_light) as example code seems fine.
While working on the sp_accept_owner change: http://svn.boost.org/trac/boost/changeset/44353 I was reminded that the enhanced esft base actually can't be done in "user mode" due to the get_deleter support. So it's not just an example; if we keep it, it has to be "official". I leave the decision (and the actual revert, should you elect to proceed) to you. It might be better to wait for a test cycle first. I'll also appreciate if you try sp_accept_owner for your existing use cases that motivated the enhanced esft base and, if possible, distill their essence into a test case that will replace (or complement) esft_constructor_test. As an aside, if people interested in the Borland compiler are listening, I have problems with sp_accept_owner_test.cpp on bcc32 5.5.1. It doesn't seem to recognize my sp_accept_owner overloads. It'd be somewhat disturbing if this persists for the later Borland versions which we test. Oddly, shared_from_this_test and esft_regtest appear to work fine, and I've no idea why.