This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++14 status.

2071. std::valarray move-assignment

Section: 29.6.2.3 [valarray.assign] Status: C++14 Submitter: Paolo Carlini Opened: 2011-05-05 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [valarray.assign].

View all issues with C++14 status.

Discussion:

Yesterday I noticed that the language we have in the FDIS about std::valarray move assignment is inconsistent with the resolution of LWG 675. Indeed, we guarantee constant complexity (vs linear complexity). We also want it to be noexcept, that is more subtle, but again it's at variance with all the containers.

Also, even if we suppose that LWG 675⁽ⁱ⁾ applies only to the containers proper, I don't think the current "as if by calling resize(v.size())" is internally consistent with the noexcept requirement.

So, what do we really want for std::valarray? Shall we maybe just strike or fix the as-if, consider it some sort of pasto from the copy-assignment text, thus keep the noexcept and constant complexity requirements (essentially the whole operation would boild down to a swap of POD data members). Or LWG 675⁽ⁱ⁾ should be explicitly extended to std::valarray too? In that case both noexcept and constant complexity would go, I think, and the operation would boil down to the moral equivalent of clear() (which doesn't really exist in this case) + swap?

Howard: I agree the current wording is incorrect. The complexity should be linear in size() (not v.size()) because the first thing this operator needs to do is resize(0) (or clear() as you put it).

I think we can keep the noexcept.

As for proper wording, here's a first suggestion:

Effects: *this obtains the value of v. The value of v after the assignment is not specified.

Complexity: linear.

See also reflector discussion starting with c++std-lib-30690.

[2012, Kona]

Move to Ready.

Some discussion on the types supported by valarray concludes that the wording is trying to say something similar to the core wording for trivial types, but significantly predates it, and does allow for types with non-trivial destructors. Howard notes that the only reason for linear complexity, rather than constant, is to support types with non-trivial destructors.

AJM suggests replacing the word 'value' with 'state', but straw poll prefers moving forward with the current wording, 5 to 2.

[2012, Portland: applied to WP]

Proposed resolution:

This wording is relative to the FDIS.

In 29.6.2.3 [valarray.assign] update as follows:

valarray<T>& operator=(valarray<T>&& v) noexcept;

3 Effects: *this obtains the value of v. If the length of v is not equal to the length of *this, resizes *this to make the two arrays the same length, as if by calling resize(v.size()), before performing the assignment.The value of v after the assignment is not specified.

4 Complexity: ConstantLinear.