Oleg Fedtchenko wrote:
shared_ptr<Tree> Parse( shared_ptr<DocActiveX> ptrOwner) { shared_ptr<Tree> ptrMember( &m_Tree, ptrOwner); return ptrMember; }
And corresponding ctor that passes over a deletable pointer to an owner (ptrOwner) of a class member (p):
template <class Y, class Z> shared_ptr( Y * p, shared_ptr<Z>& ptrOwner) : px(p), pn(ptrOwner.pn) {...}
we must specify an owner every time and easily can pass in a shared_ptr other than pointing to the right owner:
Larry Evans wrote:
Could you define a new shared_ptr templated CTOR which takes a pointer to member:
template<typename Member> struct shared_ptr { template<typename Owner, Member Owner::*pm_type> shared_ptr(shared_ptr<Owner>* a_owner, pm_type a_pm) : px(a_owner.get()->a_pm), pn(???) {} };
I haven't compiled this; hence, the syntax may not be right. How would this compare with member_ptr, and the others?
I also did not compile this piece of code. But if I caught the idea behind it right, then to place constrains on acceptable combinations *member-owner* looks surprising. An owner knows all of it members exposed through shared_ptr. And it contains all of those acceptable combinations *type of owner and its corresponding acceptable type of member*. But I had a task of hierarchy of several classes two of which were used as owners for the same type of member exposed through a smart pointer. One of those owners had a pointer to another one. If I had used a CTOR with both pointers to a member and its owner (as at the beginning) I could have passed in the pointer to another (wrong) owner instead of *this*. And the type *member-owner* constrains above would have not prevented an access violation. But member_ptr keeping a pointer to an owner in its base class does not allow to make a mistake. Oleg Fedtchenko The proposed smart pointer member_ptr is described at http://boostoleg.narod.ru/member_ptr.html thread entry http://lists.boost.org/MailArchives/boost/msg73168.php