Title
list::assign overspecified
Status
cd1
Section
[list.cons]
Submitter
Howard Hinnant

Created on 2001-05-17.00:00:00 last changed 171 months ago

Messages

Date: 2010-10-21.18:28:33

[ CuraƧao: Made editorial improvement in wording; changed "Replaces elements in a with copies of elements in [i, j)." with "Replaces the elements of a with a copy of [i, j)." Changes not deemed serious enough to requre rereview. ]

Date: 2010-10-21.18:28:33

[ Redmond: Proposed resolution was changed slightly. Previous version made explicit statement about exception safety, which wasn't consistent with the way exception safety is expressed elsewhere. Also, the change in the sequence requirements is new. Without that change, the proposed resolution would have required that assignment of a subrange would have to work. That too would have been overspecification; it would effectively mandate that assignment use a temporary. Howard provided wording. ]

Date: 2010-10-21.18:28:33

Proposed resolution:

Change [list.cons]/7 from:

Effects:

   erase(begin(), end());
   insert(begin(), first, last);

to:

Effects: Replaces the contents of the list with the range [first, last).

In [sequence.reqmts], in Table 67 (sequence requirements), add two new rows:

      a.assign(i,j)     void      pre: i,j are not iterators into a.
                                  Replaces elements in a with a copy
                                  of [i, j).

      a.assign(n,t)     void      pre: t is not a reference into a.
                                  Replaces elements in a with n copies
                                  of t.

Change [list.cons]/8 from:

Effects:

   erase(begin(), end());
   insert(begin(), n, t);

to:

Effects: Replaces the contents of the list with n copies of t.

Date: 2001-05-17.00:00:00

Section [list.cons], paragraphs 6-8 specify that list assign (both forms) have the "effects" of a call to erase followed by a call to insert.

I would like to document that implementers have the freedom to implement assign by other methods, as long as the end result is the same and the exception guarantee is as good or better than the basic guarantee.

The motivation for this is to use T's assignment operator to recycle existing nodes in the list instead of erasing them and reallocating them with new values. It is also worth noting that, with careful coding, most common cases of assign (everything but assignment with true input iterators) can elevate the exception safety to strong if T's assignment has a nothrow guarantee (with no extra memory cost). Metrowerks does this. However I do not propose that this subtlety be standardized. It is a QoI issue.

Existing practise: Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.

History
Date User Action Args
2010-10-21 18:28:33adminsetmessages: + msg2224
2010-10-21 18:28:33adminsetmessages: + msg2223
2010-10-21 18:28:33adminsetmessages: + msg2222
2001-05-17 00:00:00admincreate