Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofOpen status.

2321. Moving containers should (usually) be required to preserve iterators

Section: 23.2.2[container.requirements.general]Status:OpenSubmitter: Stephan T. LavavejOpened: 2013-09-21Last modified: 2023-01-20

Priority:3

View otheractive issues in [container.requirements.general].

View all otherissues in [container.requirements.general].

View all issues withOpen status.

Discussion:

23.2.2[container.requirements.general]/10 says that unless otherwise specified, "noswap() function invalidates any references, pointers, or iterators referring to the elements of the containers being swapped. [Note: Theend() iterator does not refer to any element, so it may be invalidated. —end note]". However, move constructors and move assignment operators aren't given similar invalidation guarantees. The guarantees need several exceptions, so I do not believe that blanket language like /11 "Unless otherwise specified (either explicitly or by defining a function in terms of other functions), invoking a container member function or passing a container as an argument to a library function shall not invalidate iterators to, or change the values of, objects within that container." is applicable.

[2014-02-13 Issaquah]

General agreeement on intent, several wording nits and additional paragraphs to hit.

STL to provide updated wording. Move to Open.

[2015-02 Cologne]

AM: in the proposed wording, I'd like to mention that the iterators now refer to elements of a different container. I think we're saying something like this somewhere. JY: There's some wording like that for swap I think. TK: It's also inlist::splice(). DK to JY: 23.2.1p9.

VV: The issue says that STL was going to propose new wording. Has he done that? AM: I believe we're looking at that. GR: The request touches on multiple paragraphs, and this PR has only one new paragraph, so this looks like it's not up-to-date. MC: This was last updated a year ago in Issaquah.

Conclusion: Skip, not up to date.

[2015-06, Telecon]

Still waiting for updated wording

[2015-08 Chicago]

Still waiting for updated wording

[2018-08-23 Batavia Issues processing]

Priority to 3

[2023-01-20; std-proposals post]

Emile Cormierobservedthat the proposed resolution of this issue contradicts with changes made byLWG2839⁽ⁱ⁾. Specifially, the current draft does not requirecontainer elements to be preserved on self-move-assignment.If this issue is accepted, it would either need to allowiterator invalidation on self-move-assignment or remove the"Ifa andrv do not refer to the same object"changes added to the container requirements by LWG2839⁽ⁱ⁾.

Proposed resolution:

This wording is relative to N3691.

1. In 23.2.2[container.requirements.general]/10 change as indicated:

   -10- Unless otherwise specified (see 23.2.4.1, 23.2.5.1, 23.3.3.4, and 23.3.7.5) all container types defined in thisClause meet the following additional requirements:

   • […]

   • no copy constructor or assignment operator of a returned iterator throws an exception.

   • no move constructor (or move assignment operator whenallocator_traits<allocator_type>::propagate_on_container_move_assignment::value is true) of a container (except forarray) invalidates any references, pointers, or iterators referring to the elements of the source container. [Note: Theend() iterator does not refer to any element, so it may be invalidated. —end note]

   • noswap() function throws an exception.

   • noswap() function invalidates any references, pointers, or iterators referring to the elements of thecontainers being swapped. [Note: Theend() iterator does not refer to any element, so it may beinvalidated. —end note]