[boost] Re: [pointer container] copyability

From: David Abrahams (dave_at_[hidden])
Date: 2005-04-27 07:32:08

Howard Hinnant <hinnant_at_[hidden]> writes:

> 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>>.  

That makes insertion in a std::vector<clone_ptr<T> > expensive.  But
this is really beside my point.

> 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 pointers are just plain pointers, so it can.

> 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.

This seems to be beside my point also.

> <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.

In preparing my notes for speaking about rvalue references at ACCU I
realized that move semantics can be fully accomplished within the
current language, if clumsily.  The forwarding problem really makes
new compilers _necessary_.  Of course, move without forwarding is not
really all that compelling anyway.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com