...
| Type | Functionality | Moved-from State |
|---|---|---|
std::unique_ptr | Move construction, Move assignment "Converting" move construction, "Converting" move assignment (Likewise for std::unique_ptr for array objects with a runtime length) | The moved-from object is guaranteed to refer to a null pointer value, per [unique.ptr], paragraph 4 [ISO/IEC 14882-2014]. |
std::shared_ptr | Move construction, Move assignment | The moved-from object shall be "empty", per [util.smartptr.shared.const], paragraph 22 and [util.smartptr.shared.assign] paragraph 4. |
std::shared_ptr | Move construction and move assignment from a std::unique_ptr | The moved-from object is guaranteed to refer to a null pointer value, per [util.smartptr.shared.const], paragraph 29 and [util.smartptr.shared.assign] paragraph 6. |
std::weak_ptr | Move construction, Move Assignment "Converting" move construction, "Converting" move assignment | The moved-from object shall be "empty", per [util.smartptr.weak.const], paragraph 8, and [util.smartptr.weak.assign], paragraph 4. |
std::basic_ios | move() | The moved-from object is still left in an unspecified state, except that rdbuf() shall return the same value as it returned before the move, and tie() shall return 0, per [basic.ios.members], paragraph 20. |
std::basic_filebuf | Move constructor, Move assignment | The moved-from object is guaranteed to reference no file; other internal state is also affected, per [filebuf.cons], paragraphs 3 and 4, and [filebuf.assign], paragraph 1. |
std::thread | Move constructor, Move assignment | Calling get_id() on the moved-from object is guaranteed to remain unchanged, but otherwise the object is in an unspecified state, per [thread.thread.constr], paragraph 11 and [thread.thread.assign], paragraph 2. |
std::unique_lock | Move constructor, Move assignment | The moved-from object is guaranteed to be in its default state, per [thread.lock.unique.cons], paragraphs 21 and 23. |
std::shared_lock | Move constructor, Move assignment | The moved-from object is guaranteed to be in its default state, per [thread.lock.shared.cons], paragraphs 21 and 23. |
std::promise | Move constructor, Move assignment | The moved-from object is guaranteed not to have any shared state, per [futures.promise], paragraphs 6 and 8. |
std::future | Move constructor, Move assignment | Calling valid() on the moved-from object is guaranteed to return false, per [futures.unique_future] paragraphs 8 and 11. |
std::shared_future | Move constructor, Move assignment "Converting" move constructor, "Converting" move assignment | Calling valid() on the moved-from object is guaranteed to return false, per [futures.shared_future] paragraphs 8 and 11. |
std::packaged_task | Move constructor, Move assignment | The moved-from object is guaranteed not to have any shared state, per [future.task.members], paragraphs 7 and 8. |
Several generic standard template library (STL) algorithms, such as std::remove() and std::unique(), remove instances of elements from a container without shrinking the size of the container. Instead, these algorithms return a ForwardIterator to indicate the partition within the container after which elements are no longer valid. The elements in the container that precede the returned iterator are valid elements with specified values, whereas the elements that succeed the returned iterator are valid but have unspecified values. Accessing unspecified values of elements iterated over results in unspecified behavior. Frequently, the erase-remove idiom is used to shrink the size of the container when using these algorithms.
Noncompliant Code Example
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
#include <iostream>
#include <string>
void g(std::string &&v) {
std::cout << v << std::endl;
}
void f() {
for (unsigned i = 0; i < 10; ++i) {
std::string s(1, static_cast<char>('0' + i));
g(std::move(s));
}
} |
Noncompliant Code Example
In this noncompliant code example, elements matching 42 are removed from the given container. The contents of the container are then printed to the standard output stream. However, if any elements were removed from the container, the range-based for loop iterates over an invalid iterator range, resulting in unspecified behavior.
| Code Block | ||||
|---|---|---|---|---|
| ||||
#include <algorithm>
#include <iostream>
#include <vector>
void f(std::vector<int> &c) {
std::remove(c.begin(), c.end(), 42);
for (auto v : c) {
std::cout << "Container element: " << v << std::endl;
}
} |
Compliant Solution
In this compliant solution, elements removed by the standard algorithm are skipped during iteration.
| Code Block | ||||
|---|---|---|---|---|
| ||||
#include <algorithm>
#include <iostream>
#include <vector>
void f(std::vector<int> &c) {
auto e = std::remove(c.begin(), c.end(), 42);
for (auto i = c.begin(); i != c.end(); i++) {
if (i < e) {
std::cout << *i << std::endl;
}
}
} |
Compliant Solution
In this compliant solution, elements removed by the standard algorithm are subsequently erased from the given container. This technique ensures that a valid iterator range is used by the range-based for loop.
| Code Block | ||||
|---|---|---|---|---|
| ||||
#include <algorithm> #include <iostream> #include <vector> void f(std::vector<int> &c) { c.erase(std::remove(c.begin(), c.end(), 42), c.end()); for (auto v : c) { std::cout << "Container element: " << v << std::endl; } } |
Risk Assessment
The state of a moved-from object is generally valid, but unspecified. Relying on unspecified values can lead to abnormal program termination, as well as data integrity violations.
...