Boost logo

Boost :

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

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

> 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;
    // ...
    // or



Boost list run by bdawes at, gregod at, cpdaniel at, john at