[boost] [ptr_container] references & copyability etc (was [ptr_container] indirect_fun - do we still need it?)

From: Pavel Chikulaev (pavel.chikulaev_at_[hidden])
Date: 2005-05-11 15:53:48

"Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message 
news:d5tnql$2ll$1_at_sea.gmane.org...
> what do you need the returned reference for?
Just remembering rule: "Create your own classes that behave like int". isn't it?
And IMO we should return reference to do these things:

template<typename T>
class ptr_cc_vector : public ptr_vector<T> //User's class to enable copyability
{
public:
    ptr_cc_vector(const ptr_cc_vector & that) : ptr_vector<T>(that.clone()) {}

    ptr_cc_vector & operator = (const ptr_cc_vector & that)
    {
        return *this = that.clone(); // :)))
        //Above is a bit better than
        //*this = that.clone();
        //return *this; :))
    }
};

So, using ptr_container::clone is some kind of _very_ explicit copy constucting 
and assignment operator.
Compare:
a = b;
a = ( b.clone() );
a(b);
a( b.clone() );
and should behave like oridinal copy ctor and operator =.

///////////////////////////

Let's start a new discussion about copyability :)

I find ptr_cc_vector<T> very handy. Why not just enable copy ctor and assignment 
operator
but in docs you will say explicitly that invoking copy ctor and assignment 
operator can be very very expensive in capital letters??

Or compromise: Add policy class
By default ptr_containers are not copyconstructible, but it can be redefined if 
someone is willing to make ptr_containers copyconstructible
template<typename T, ...., bool EnableCopyCtorAnd = DefaultBehavior>
class ptr_vector;

Someone, like you, will make DefaultBehavior for his ptr_containers Forbid.
Someone, like me, will make DefaultBehavior for his ptr_containers Permit.

IMO quite flexible, and everybody will be happy :)

P.S. What's about clone_allocators -  are they going to be not stateless or not?

--
Pavel Chikulaev