besides implementation issues regarding proper creation and destruction of a clone_ptr, it seems that you're trying to achieve few goals in one class. you're talking about the clone problem which is a complete problem on its own and then you're talking about pointers in stl containers and algorithms, and as a result you came out with a class that tries to solve both problems. these two problems are completeley unrelated, you can itroduce a simple adaptor that modifies an existing pointer type (smart or not...) into a comparable class (I've implemented one in a few minutes) and you can write a seperate class that takes care of clowning (possible or not, I don't know, follow the thread), then you can wrap it all together using a typedef and get a simpler, more flaxible and robust design. then you can readopt the entire thing using another adaptor... (*i.e. copy on write.) by the way, this is the approach taken by the iterator adaptors library, if you need a filter and transform iterator you simply apply a transform iterator adaptor to a filter iterator adaptor applied to the base iterator. eyal. -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Martin Bonner Sent: Tuesday, August 16, 2005 12:17 PM To: 'boost@lists.boost.org' Subject: Re: [boost] Propose adding Clone Smart Pointer (clone_ptr) to the boost library ----Original Message---- From: Axter [mailto:boost@axter.com] Sent: 16 August 2005 03:39 To: boost@lists.boost.org Subject: [boost] Propose adding Clone Smart Pointer (clone_ptr) to the boost library

I'm proposing to add the clone_ptr class to the boost library.

I've developed a clone_ptr class that performs a clone of an abstract pointer without the need for a clone method.

The clone_ptr is well suited for automatic deep copy of abstract pointers, and for use with STL containers.

In addition to being able to perform clone operations, it also have operators that performs comparison on the object being pointed to, instead of the pointer address. This allows for correct sorting and comparison of clone_ptr's in an STL container. See following link for more info: http://code.axter.com/clone_ptr_introduction.htm

I was interested in the example you give in the web page: class foo { clone_ptr < AbstractClass > m_MyAbstractClassPtr; public: foo(AbstractClass * abstractclassptr_):m_MyAbstractClassPtr(abstractclassptr_){} foo(const foo& Src) { //In the following line of code, the clone pointer will copy the // correct derived class without the need of a clone method m_MyAbstractClassPtr = Src.m_MyAbstractClassPtr; } }; 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. 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 would also be useful to have some documentation of what methods clone_ptr provides, and what effects they have. -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost