247. vector, deque::insert complexity

Section: 26.3.11.5 [vector.modifiers] Status: CD1 Submitter: Lisa Lippincott Opened: 2000-06-06 Last modified: 2016-02-10

Priority: Not Prioritized

View all other issues in [vector.modifiers].

View all issues with CD1 status.

Discussion:

Paragraph 2 of 26.3.11.5 [vector.modifiers] describes the complexity of vector::insert:

Complexity: If first and last are forward iterators, bidirectional iterators, or random access iterators, the complexity is linear in the number of elements in the range [first, last) plus the distance to the end of the vector. If they are input iterators, the complexity is proportional to the number of elements in the range [first, last) times the distance to the end of the vector.

First, this fails to address the non-iterator forms of insert.

Second, the complexity for input iterators misses an edge case -- it requires that an arbitrary number of elements can be added at the end of a vector in constant time.

I looked to see if deque had a similar problem, and was surprised to find that deque places no requirement on the complexity of inserting multiple elements (26.3.8.4 [deque.modifiers], paragraph 3):

Complexity: In the worst case, inserting a single element into a deque takes time linear in the minimum of the distance from the insertion point to the beginning of the deque and the distance from the insertion point to the end of the deque. Inserting a single element either at the beginning or end of a deque always takes constant time and causes a single call to the copy constructor of T.

Proposed resolution:

Change Paragraph 2 of 26.3.11.5 [vector.modifiers] to

Complexity: The complexity is linear in the number of elements inserted plus the distance to the end of the vector.

[For input iterators, one may achieve this complexity by first inserting at the end of the vector, and then using rotate.]

Change 26.3.8.4 [deque.modifiers], paragraph 3, to:

Complexity: The complexity is linear in the number of elements inserted plus the shorter of the distances to the beginning and end of the deque. Inserting a single element at either the beginning or the end of a deque causes a single call to the copy constructor of T.

Rationale:

This is a real defect, and proposed resolution fixes it: some complexities aren't specified that should be. This proposed resolution does constrain deque implementations (it rules out the most naive possible implementations), but the LWG doesn't see a reason to permit that implementation.