From: Oleg Fedtchenko (BoostOleg_at_[hidden])
Date: 2004-10-18 14:18:42
>> 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
> 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.
The proposed smart pointer member_ptr is described at
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk