Re: [boost] [pointer container] copyability

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2005-04-26 12:44:12

On Apr 26, 2005, at 12:08 PM, David Abrahams wrote:

> I had this disagreement with Thorsten in Lillehammer (or was it
> Oxford?) but he was unimpressed with my arguments.  I was wondering
> what Boost as a whole would think:
>
> My Thesis: the library should support copying and assignment of
>   pointer containers using the usual copy/assignment syntax, rather
>   than only allowing a copy via a clone() function.
>
> Rationale: Not being able to copy and assign pointer containers is an
>   arbitrary restriction that limits usefulness and expressivity.  The
>   argument Thorsten gives against copyability is that the elements
>   would have to be clone()d rather than copied, which is expensive
>   because there's a dynamic allocation per element.  I don't get it;
>   we don't arbitrarily prohibit copying of std::vector<std::string>
>   even though that incurs a dynamic allocation per element.
>
> Example: Consider std::pair<int,some_pointer_container>.  Almost
>   nothing works. IIUC, it's not copyable, can't be initialized, and
>   can't be clone()d.

Why not just a clone_ptr<T> which calls clone on copy construction / 
assignment?  Then you could std::container<clone_ptr<T>>.  And such a 
container is copyable (clones on copy).  An indirection iterator 
adaptor could ease use of this container with algorithms, as could 
indirect comparitors.

std::list<clone_ptr<T>> might be the container of choice in the short 
term since list doesn't copy around its elements at the drop of a hat.

In C++0X, (I believe) none of the containers will unnecessarily copy 
clone_ptr's, choosing to internally move them instead (moving a 
clone_ptr would be cheap).

On your thesis:  The library should only support copying and assignment 
of pointer containers using the usual copy/assignment syntax if a 
non-destructive copy of the pointer can be made.  The proposed 
std::container<unique_ptr<T>> won't be such a container.  Having 
std::container<auto_ptr<T>> fail at compile time is still a good idea.  
Otherwise it would destructively copy with copy syntax.

<sigh>  I realize these thoughts are a little ahead of their time at 
the moment due to the lack of compilers/libs which would make 
std::vector<clone_ptr<T>> acceptably efficient.

-Howard