[array] assignement operator
Boost.Array defines an assignement operator with the following prototype template<typename T, std::size_t N> class array { public: /... template<typename U> array& operator=(const array<U, N>& rhs); // Effects:std::copy(rhs.begin(),rhs.end(), begin()) }; 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? Best, _____________________ Vicente Juan Botet Escribá
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. 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. Regards, Joe. On Fri, May 15, 2009 at 12:28 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Boost.Array defines an assignement operator with the following prototype
template<typename T, std::size_t N> class array { public: /... template<typename U> array& operator=(const array<U, N>& rhs); // Effects:std::copy(rhs.begin(),rhs.end(), begin()) };
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?
Best, _____________________ Vicente Juan Botet Escribá
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Joseph Gauterin wrote: On Friday, May 15, 2009 7:52 AM
On Fri, May 15, 2009 at 12:28 PM, vicente.botet <vicente.botet@wanadoo.fr> 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. 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. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Hi, ----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> 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@wanadoo.fr> 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
vicente.botet wrote: On Friday, May 15, 2009 11:46 AM
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);
I like that idea, though I'd name it "subarray." I'd expect these to fail at compile time: subarray<0,4>(a) = b; b = subarray<0,4>; but not these: subarray<0,5>(a) = b; b = subarray<0,5>(a); Thus, I see subarray as having its size specified by the second template parameter and the offset into the array as the first template parameter. This should also be possible: subarray<6,3>(a) = subarray<1,3>(b); Notice how the "3" matches in that statement, clearly showing that the two subarrays have the same length.
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);
I don't like that. The argument order isn't intuitive and the odd behavior isn't made clear by the name. Besides, I think subarray handles every use case and makes the subset assignment behavior clear. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
What's wrong with using the assignment operator for arrays of equal size and using std::copy otherwise?
Hi, ----- Original Message ----- From: "Joseph Gauterin" <joseph.gauterin@googlemail.com> To: <boost@lists.boost.org> Sent: Monday, May 18, 2009 3:32 PM Subject: Re: [boost] [array] assignement operator
What's wrong with using the assignment operator for arrays of equal size and using std::copy otherwise?
I don't think there is nothing wrong, just that copying sub-arrays of the same size, with the size known staticaly, can be improbed respect to std::copy. The assignement operator for arrays of equal size can use this static information, but the std::copy can not because it is based on iterators. Of course when the size is know at runtime std::copy is the good option. Best, Vicente
AMDG vicente.botet wrote:
I don't think there is nothing wrong, just that copying sub-arrays of the same size, with the size known staticaly, can be improbed respect to std::copy. The assignement operator for arrays of equal size can use this static information, but the std::copy can not because it is based on iterators. Of course when the size is know at runtime std::copy is the good option.
Whatever happened to inlining and compiler optimizations? Have you actually measured any difference? In Christ, Steven Watanabe
Hi, ----- Original Message ----- From: "Steven Watanabe" <watanabesj@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, May 19, 2009 2:01 AM Subject: Re: [boost] [array] assignement operator
AMDG
vicente.botet wrote:
I don't think there is nothing wrong, just that copying sub-arrays of the same size, with the size known staticaly, can be improbed respect to std::copy. The assignement operator for arrays of equal size can use this static information, but the std::copy can not because it is based on iterators. Of course when the size is know at runtime std::copy is the good option.
Whatever happened to inlining and compiler optimizations?
As usual you should be right. The compiler should be able to optimize these.
Have you actually measured any difference?
and you are right again. I should measure before posting. I'll try to do it soon. Thanks, Vicente
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Friday, May 15, 2009 6:16 PM Subject: Re: [boost] [array] assignement operator
vicente.botet wrote: On Friday, May 15, 2009 11:46 AM
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);
I like that idea, though I'd name it "subarray." I'd expect these to fail at compile time:
subarray<0,4>(a) = b; b = subarray<0,4>;
but not these:
subarray<0,5>(a) = b; b = subarray<0,5>(a);
Thus, I see subarray as having its size specified by the second template parameter and the offset into the array as the first template parameter.
This should also be possible:
subarray<6,3>(a) = subarray<1,3>(b);
Notice how the "3" matches in that statement, clearly showing that the two subarrays have the same length.
Yeah, this is clear. We can have a class 'subarray_view' and a factory function 'subarray'. subarray_view is a kind of static range.
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);
I don't like that. The argument order isn't intuitive and the odd behavior isn't made clear by the name. Besides, I think subarray handles every use case and makes the subset assignment behavior clear.
You are right, in order to have b = subarray<0,5>(a); efficient we need to overload the assignement operator on the array class. If no modification is made on the array class an 'assign' function can always be implemented efficiently. assign(b,subarray<0,5>(a)); Thanks, Vicente
Hi, This is already the case. Implicit conversions suffer of inequality after assignement, array<int, 2> a; array<double, 2> b; b[0]=0.5; b[1]=1.5; a=b; assert(a!=b); and this is not the single case; other classes suffer from the same symptom as std::pair. Do you find this counter-intuitive? Vicente ----- Original Message ----- From: "Joseph Gauterin" <joseph.gauterin@googlemail.com> To: <boost@lists.boost.org> Sent: Friday, May 15, 2009 1:51 PM Subject: Re: [boost] [array] assignement operator 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. 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. Regards, Joe. On Fri, May 15, 2009 at 12:28 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Boost.Array defines an assignement operator with the following prototype
template<typename T, std::size_t N> class array { public: /... template<typename U> array& operator=(const array<U, N>& rhs); // Effects:std::copy(rhs.begin(),rhs.end(), begin()) };
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?
Best, _____________________ Vicente Juan Botet Escribá
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, May 15, 2009 at 12:28 PM, vicente.botet <vicente.botet@wanadoo.fr>wrote:
Is there anything wrong with this interface?
It's pretty horrible, but if you really insist you might be able to get the behaviour you want from multi_array and multi_array_ref. I've not really thought it through, but since it offers the ability to interpret an arbitary block of memory as its data, you may be able to pervert it sufficiently. Just a thought. - Rob.
participants (5)
-
Joseph Gauterin -
Robert Jones -
Steven Watanabe -
Stewart, Robert -
vicente.botet