Containers library
The Containers library is a generic collection of class templates and algorithms that allow programmers to easily implement common data structures like queues, lists and stacks. There are three classes of containers -- sequence containers, associative containers, and unordered associative containers -- each of which is designed to support a different set of operations.
The container manages the storage space that is allocated for its elements and provides member functions to access them, either directly or through iterators (objects with properties similar to pointers).
Most containers have at least several member functions in common, and share functionalities. Which container is the best for the particular application depends not only on the offered functionality, but also on its efficiency for different workloads.
Sequence containers
Sequence containers implement data structures which can be accessed sequentially.
(C++11) |
static contiguous array (class template) |
dynamic contiguous array (class template) | |
double-ended queue (class template) | |
(C++11) |
singly-linked list (class template) |
doubly-linked list (class template) |
Associative containers
Associative containers implement sorted data structures that can be quickly searched (O(log n) complexity).
collection of unique keys, sorted by keys (class template) | |
collection of key-value pairs, sorted by keys, keys are unique (class template) | |
collection of keys, sorted by keys (class template) | |
collection of key-value pairs, sorted by keys (class template) |
Unordered associative containers
Unordered associative containers implement unsorted (hashed) data structures that can be quickly searched (O(1) amortized, O(n) worst-case complexity).
(C++11) |
collection of unique keys, hashed by keys (class template) |
(C++11) |
collection of key-value pairs, hashed by keys, keys are unique (class template) |
(C++11) |
collection of keys, hashed by keys (class template) |
(C++11) |
collection of key-value pairs, hashed by keys (class template) |
Container adaptors
Container adaptors provide a different interface for sequential containers.
adapts a container to provide stack (LIFO data structure) (class template) | |
adapts a container to provide queue (FIFO data structure) (class template) | |
adapts a container to provide priority queue (class template) |
span
A span
is a non-owning view over a contiguous sequence of objects, the storage of which is owned by some other object.
(C++20) |
a non-owning view over a contiguous sequence of objects (class template) |
Iterator invalidation
Read-only methods never invalidate iterators or references. Methods which modify the contents of a container may invalidate iterators and/or references, as summarized in this table.
Category | Container | After insertion, are... | After erasure, are... | Conditionally | ||
---|---|---|---|---|---|---|
iterators valid? | references valid? | iterators valid? | references valid? | |||
Sequence containers | array | N/A | N/A | |||
vector | No | N/A | Insertion changed capacity | |||
Yes | Yes | Before modified element(s) | ||||
No | No | At or after modified element(s) | ||||
deque | No | Yes | Yes, except erased element(s) | Modified first or last element | ||
No | No | Modified middle only | ||||
list | Yes | Yes, except erased element(s) | ||||
forward_list | Yes | Yes, except erased element(s) | ||||
Associative containers | set | Yes | Yes, except erased element(s) | |||
Unordered associative containers | unordered_set | No | Yes | N/A | Insertion caused rehash | |
Yes | Yes, except erased element(s) | No rehash |
Here, insertion refers to any method which adds one or more elements to the container and erasure refers to any method which removes one or more elements from the container.
- Examples of insertion methods are std::set::insert, std::map::emplace, std::vector::push_back, and std::deque::push_front.
- Note that std::unordered_map::operator[] also counts, as it may insert an element into the map.
- Examples of erasure methods are std::set::erase, std::vector::pop_back, std::deque::pop_front, and std::map::clear.
-
clear
invalidates all iterators and references. Because it erases all elements, this technically complies with the rules above.
-
The past-the-end iterator deserves particular mention. In general this iterator is invalidated as though it were a normal iterator to a non-erased element. So std::set::end is never invalidated, std::unordered_set::end is invalidated only on rehash, std::vector::end is always invalidated (since it is always after the modified elements), and so on.
There is one exception: an erasure which deletes the last element of a std::deque does invalidate the past-the-end iterator, even though it is not an erased element of the container (or an element at all). Combined with the general rules for std::deque iterators, the net result is that the only modifying operation which does not invalidate std::deque::end is an erasure which deletes the first element, but not the last.
Thread safety
|
(since C++11) |
Member function table
- functions present in C++03 | |
- functions present since C++11 | |
- functions present since C++17 | |
- functions present since C++20 |