Re: [boost] [array] assignement operator

Subject: Re: [boost] [array] assignement operator
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-05-15 11:46:01

Hi,
----- Original Message ----- 
From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, May 15, 2009 2:24 PM
Subject: Re: [boost] [array] assignement operator

> 
> Joseph Gauterin wrote:
> On Friday, May 15, 2009 7:52 AM
>> On Fri, May 15, 2009 at 12:28 PM, vicente.botet
>> <vicente.botet_at_[hidden]> wrote:
>>
>> > Boost.Array defines an assignement operator with the
>> following prototype
> 
> [snip expected copy assignment operator]
> 
>> > I was wondering if this can be extended to manage with
>> arrays of different sizes, having as effect the copying of
>> the minimum of N and M elements from the source to the target.
>> >
>> > template<typename T, std::size_t N>
>> > class array {
>> > public:
>> >    /...
>> >    template<typename U, std::size_t M>
>> >    array& operator=(const array<U, M>& rhs);
>> >    // Effects:std::copy(rhs.begin(),rhs.begin()+min(N,M), begin())
>> > };
>> >
>> > Is there anything wrong with this interface?
>>
>> I think such an assignment operator is counter-intuitive and its use
>> will lead to hard to read code. I'd expect two objects to be
>> equivalent after one is assigned to the other.
> 
> This is absolutely the case.  That's the point of copy assignment operators, std::auto_ptr and a few other classes notwithstanding!  For example, Rogue Wave provides a substring class for their string class that uses the copy assignment operator to update the referenced string, not to make the destination substring equivalent to the source.  While it provides a convenient interface, it also leads to surprises, particularly for the uninitiated.
> 
>> I certainly wouldn't
>> expect an array on the LHS to still contain some of its original
>> elements after a smaller RHS array is assigned to it.
> 
> array is unusual in that the elements begin with indeterminate values when not constructed from an initializer list, and size() always returns N, so its behavior is unusual for a container however you look at it.  Retaining the original values is the only possible behavior for such a function when the source is larger than the destination.  It would also be surprising to find only a subset of a larger source in the destination when using a copy assignment operator, but array doesn't grow.

Is the following more intuitive?

    array<int,10> a;
    array<int, 5> b;

    as_sub_array<0,4>(a) = b;
    // or 
    b=as_sub_array<2,6>(a);

 
> The suggested idea may have its uses, but it has sufficiently odd behavior that it ought not to be a member function and certainly not the copy assignment operator.  Perhaps a free function is in order.

Do you think that an specialization of a assign_to function would be intuitive

    array<int, 5> a;
    array<int, 2> b;
    // ...
    assign_to(b,a);
    // or

    assign_to(b,as_sub_array<0,1>a);

Best,
Vicente