This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD Editorial status.
Section: 24.2.4 [sequence.reqmts] Status: NAD Editorial Submitter: Nicolai Josuttis Opened: 2010-01-01 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [sequence.reqmts].
View all other issues in [sequence.reqmts].
View all issues with NAD Editorial status.
I propose that clear() be defined to be equivalent to erase(begin(),end()) except not using copy or move of elements.
To: C++ libraries mailing list
and specifiying as post: size()==0 might also not be appropriate because forward-Lists provide no size(), this it should be: post: empty()==true
Bjarne Stroustrup schrieb/wrote:
To: C++ libraries mailing list
in table 94 we define clear() as:a.clear() void erase(begin(), end()) post: size() == 0
Now erase requires assignment (MoveAssignable) which makes sense if we have to move an element, but why should that be required from clear() where all elements are destroyed?
[ 2010-01-23 Alisdiar provides wording. ]
[ 2010-01-30 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]
[ 2010-01-30 Daniel opens: ]
First, I read the newly proposed spec for clear() that it does in general not invalidate a previous past-the-end iterator value, but deque says in 18.104.22.168 [deque.modifiers] for the semantics of erase that erasures at the end will invalidate the past-the-end iterator. With removal of a direct binding between clear() and erase() there seem to be some fixes necessary. One way to fix that would be to mention in Table 94 that this "may also invalidate the past-the-end iterator" and then to mention for all specific containers where this does not happen, the exception,  e.g. in std::vector. std::vector has no own specification of clear() and one aspect of the closed issue 1102 was to realize just that (indirectly via erase). IMO we should now add an extra specification for clear(). Btw.: std::vector::erase reads to me that it would invalidate previous past-the-end values (and that seems correct in general).
Before I will provide explicit wording, I would like to discuss these points.
 std::list does fortunately specify that clear does not invalidate the past-the-end iterator.
[ 2010-02-08 Moved to Tentatively NAD Editorial after 5 positive votes on c++std-lib. Rationale added below. ]
Solved as proposed by LWG 704.
Change 24.2.2 [container.requirements.general]/10:
Unless otherwise specified (see 22.214.171.124, 126.96.36.199, 188.8.131.52, and 184.108.40.206) all container types defined in this Clause meet the following additional requirements:
- no erase(), pop_back() or pop_front() function throws an exception.
Replace the following words from Table 94 — Sequence container requirements (in addition to container) in 24.2.4 [sequence.reqmts]:
Table 94 — Sequence container requirements (in addition to container) Expression Return type Assertion/note
a.clear() void erase(begin(), end())
size() == 0.
Add a new paragraph after [forwardlist.modifiers]/23:
23 Effects: Erases all elements in the range [begin(),end()).