Re: [boost] Propose adding Clone Smart Pointer (clone_ptr) to the boost library

From: Eyal Farago (eyal.farago_at_[hidden])
Date: 2005-08-16 10:09:42

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_at_[hidden]
[mailto:boost-bounces_at_[hidden]]On Behalf Of Martin Bonner
Sent: Tuesday, August 16, 2005 12:17 PM
To: 'boost_at_[hidden]'
Subject: Re: [boost] Propose adding Clone Smart Pointer (clone_ptr) to
the boost library

----Original Message----
From: Axter [mailto:boost_at_[hidden]]
Sent: 16 August 2005 03:39
To: boost_at_[hidden]
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_at_[hidden]
Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ,
ENGLAND Tel: [phone]
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost