320. list::assign overspecified

Section: [list.cons] Status: CD1 Submitter: Howard Hinnant Opened: 2001-05-17 Last modified: 2016-01-28 10:19:27 UTC

Priority: Not Prioritized

View all other issues in [list.cons].

View all issues with CD1 status.


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.

Proposed resolution:

Change [list.cons]/7 from:


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


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

In 24.2.4 [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:


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


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

[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. ]

[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.]