David Abrahams wrote:
Martin Bonner <martin.bonner@pitechnology.com> writes:
That looked a very clever trick. I couldn't see how clone_ptr was going to copy the dynamic type of the argument to the constructor without any information about that dynamic type.
Having looked at the code, I don't think it does.
Right, I went through the same thing. The documentation claims a bit too much for this library. I expected to find some magic in the library but instead I found what I already knew to be the practical limitation of C++: the copying logic is captured based on the static type of the pointer with which the original smart pointer was initialized, not on the dynamic type of the object referred to.
Which is why ptr_container requires a clone() member to ensure the dynamic type is available when copying. Clone_ptr has no way to access the dynamic type.
It would work if the constructor was declared: foo(DerivedClass*p): m_MyAbstractClassPtr(p) {} or even template <class Derived> foo(Derived *p):m_MyAbstractClassPtr(p) {}
but even that will fail if the constructor is called via: Derived *p = new DerivedDerived; foo foo_obj(p);
My basic concern is that while clone_ptr could be useful, it only works if people stick rigidly to certain rules. Those rules need to be made VERY clear, otherwise it provides a plentiful supply of rope.
It's basically the same rules as shared_ptr, so I don't think it's too
Except that a virtual dtor will ensure the correct destructor is run according to the dynamic type. Shared_ptr is concerned with destruction, and gets it right. Clone_ptr is about creation, and doesn't always get it right.
bad. However, we're reviewing Dave and Andrei's policy_ptr soon so it might be better to use that framework for something like this.
I think ptr_container provides a safer and more generic solution to the problems described in the rationale for clone_ptr. jon