Is it safe to assume that any pointers I have to elements inside of an std::deque are still valid after moving the deque to another one with the move constructor?
For std::vector I cannot see any reason why they wouldn't be, but I'm not familiar enough with std::deque to be sure I can make the same assumption.
Pointers to elements would remain valid. After move construction:
After container move construction (overload (8)), references, pointers, and iterators (other than the end iterator) to other remain valid, but refer to elements that are now in *this. The current standard makes this guarantee via the blanket statement in [container.requirements.general]/12, and a more direct guarantee is under consideration via LWG 2321.
Related
I have read some hints here and there that after inserting an object into a c++ stl map, then as long as one doesn't delete it, its location in memory never changes. But nobody ever mentioned any literature or sources to back it up, so I don't know how reliable such hints are. Can anyone answer this definately/reliably? Could it be implementation-dependent? Is there a guarantee anywhere?
Does a C++ STL Map move a value's location around after creation?
No.
Can anyone answer this definately/reliably?
You can rely on it.
Could it be implementation-dependent?
It couldn't be dependent on implementation.
Is there a guarantee anywhere?
Yes, it is guaranteed in the C++ standard:
[container.rev.reqmts]
Unless otherwise specified (either explicitly or by defining a function in terms of other functions), invoking a container member function or passing a container as an argument to a library function shall not invalidate iterators to, or change the values of, objects within that container.
[associative.reqmts.general]
The insert, insert_range, and emplace members shall not affect the validity of iterators and references to the container, and the erase members shall invalidate only iterators and references to the erased elements.
The extract members invalidate only iterators to the removed element; pointers and references to the removed element remain valid.
However, accessing the element through such pointers and references while the element is owned by a node_type is undefined behavior.
References and pointers to an element obtained while it is owned by a node_type are invalidated if the element is successfully inserted.
I have a container C of some elements. In my algorithm, these elements need to be split into two sub-groups C1 and C2, where they will be ordered. Now, in order to avoid storing the same data twice, these two subgroups can either be
std::sets of pointers pointing to the elements in the container C, or
std::sets of iterators pointing to the elements in the container C.
I know that it would work well with iterators when following the Invalidation rules, however I will only be using C1 and C2 sets to dereference the actual value and to move the pointer/iterator from C1 to C2 or the other way around, nothing else.
Conceptually, it makes more sense to me to use pointers, but I'm not sure about two things:
Could the use of pointers actually save some memory for some std containers? (since iterators are generalization of pointers)
Do the Invalidation rules also apply for raw pointers for all std containers?
Could the use of pointers actually save some memory for some std containers?
From my standpoint, I think pointer will always cost less or equal to iterator. When you use pointer, it will cost you a pointer. While the iterator implementation which is differ from implementation to implementation, but it must have some ways to refer to original container, which will cost you a pointer or a reference, which will in the best case will cost you as much as a pointer. And this test seems support me.
Do the Invalidation rules also apply for raw pointers for all std containers?
From C++ FAQ:
Important note: Even though a reference is often implemented using an address in the underlying assembly language, please do not think of a reference as a funny looking pointer to an object. A reference is the object. It is not a pointer to the object, nor a copy of the object. It is the object.
Then whatever operation on those container which doesn't invalidate the reference in your linked question will not invalidate pointer even if that operation invalidate the iterator, which is the case of unordered_[multi]{set,map} insertion.
If I have an iterator into vector a, then I move-construct or move-assign vector b from a, does that iterator still point to the same element (now in vector b)? Here's what I mean in code:
#include <vector>
#include <iostream>
int main(int argc, char *argv[])
{
std::vector<int>::iterator a_iter;
std::vector<int> b;
{
std::vector<int> a{1, 2, 3, 4, 5};
a_iter = a.begin() + 2;
b = std::move(a);
}
std::cout << *a_iter << std::endl; // Is a_iter valid here?
return 0;
}
Is a_iter still valid since a has been moved into b, or is the iterator invalidated by the move? For reference, std::vector::swap does not invalidate iterators.
While it might be reasonable to assume that iterators are still valid after a move, I don't think the Standard actually guarantees this. Therefore, the iterators are in an undefined state after the move.
There is no reference I can find in the Standard which specifically states that iterators that existed before a move are still valid after the move.
On the surface, it would seem to be perfectly reasonable to assume that an iterator is typically implemented as pointers in to the controlled sequence. If that's the case, then the iterators would still be valid after the move.
But the implementation of an iterator is implementation-defined. Meaning, so long as the iterator on a particular platform meets the requirements set forth by the Standard, it can be implemented in any way whatsoever. It could, in theory, be implemented as a combination of a pointer back to the vector class along with an index. If that's the case, then the iterators would become invalid after the move.
Whether or not an iterator is actually implemented this way is irrelevant. It could be implemented this way, so without a specific guarantee from the Standard that post-move iterators are still valid, you cannot assume that they are. Bear in mind also that there is such a guarantee for iterators after a swap. This was specifically clarified from the previous Standard. Perhaps it was simply an oversight of the Std comittee to not make a similar clarification for iterators after a move, but in any case there is no such guarantee.
Therefore, the long and the short of it is you can't assume your iterators are still good after a move.
EDIT:
23.2.1/11 in Draft n3242 states that:
Unless otherwise specified (either explicitly or by defining a
function in terms of other functions), invoking a container member
function or passing a container as an argument to a library function
shall not invalidate iterators to, or change the values of, objects
within that container.
This might lead one to conclude that the iterators are valid after a move, but I disagree. In your example code, a_iter was an iterator in to the vector a. After the move, that container, a has certainly been changed. My conclusion is the above clause does not apply in this case.
I think the edit that changed move construction to move assignment changes the answer.
At least if I'm reading table 96 correctly, the complexity for move construction is given as "note B", which is constant complexity for anything except std::array. The complexity for move assignment, however, is given as linear.
As such, the move construction has essentially no choice but to copy the pointer from the source, in which case it's hard to see how the iterators could become invalid.
For move assignment, however, the linear complexity means it could choose to move individual elements from the source to the destination, in which case the iterators will almost certainly become invalid.
The possibility of move assignment of elements is reinforced by the description: "All existing elements of a are either move assigned to or destroyed". The "destroyed" part would correspond to destroying the existing contents, and "stealing" the pointer from the source -- but the "move assigned to" would indicate moving individual elements from source to destination instead.
tl;dr : Yes, moving a std::vector<T, A> possibly invalidates the iterators
The common case (with std::allocator in place) is that invalidation does not happen but there is no guarantee and switching compilers or even the next compiler update might make your code behave incorrect if you rely on the fact the your implementation currently does not invalidate the iterators.
On move assignment:
The question whether std::vector iterators can actually remain valid after move-assignment is connected with the allocator awareness of the vector template and depends on the allocator type (and possibly the respective instances thereof).
In every implementation I have seen, move-assignment of a std::vector<T, std::allocator<T>>1 will not actually invalidate iterators or pointers. There is a problem however, when it comes down to making use of this, as the standard just cannot guarantee that iterators remain valid for any move-assignment of a std::vector instance in general, because the container is allocator aware.
Custom allocators may have state and if they do not propagate on move assignment and do not compare equal, the vector must allocate storage for the moved elements using its own allocator.
Let:
std::vector<T, A> a{/*...*/};
std::vector<T, A> b;
b = std::move(a);
Now if
std::allocator_traits<A>::propagate_on_container_move_assignment::value == false &&
std::allocator_traits<A>::is_always_equal::value == false && (possibly as of c++17)
a.get_allocator() != b.get_allocator()
then b will allocate new storage and move elements of a one by one into that storage, thus invalidating all iterators, pointers and references.
The reason is that fulfillment of above condition 1. forbidds move assignment of the allocator on container move. Therefore, we have to deal with two different instances of the allocator. If those two allocator objects now neither always compare equal (2.) nor actually compare equal, then both allocators have a different state. An allocator x may not be able to deallocate memory of another allocator y having a different state and therefore a container with allocator x cannot just steal memory from a container which allocated its memory via y.
If the allocator propagates on move assignment or if both allocators compare equal, then an implementation will very likely choose to just make b own as data because it can be sure to be able to deallocate the storage properly.
1: std::allocator_traits<std::allocator<T>>::propagate_on_container_move_assignment and std::allocator_traits<std::allocator<T>>::is_always_equal both are typdefs for std::true_type (for any non-specialized std::allocator).
On move construction:
std::vector<T, A> a{/*...*/};
std::vector<T, A> b(std::move(a));
The move constructor of an allocator aware container will move-construct its allocator instance from the allocator instance of the container which the current expression is moving from. Thus, the proper deallocation capability is ensured and the memory can (and in fact will) be stolen because move construction is (except for std::array) bound to have constant complexity.
Note: There is still no guarantee for iterators to remain valid even for move construction.
On swap:
Demanding the iterators of two vectors to remain valid after a swap (now just pointing into the respective swapped container) is easy because swapping only has defined behaviour if
std::allocator_traits<A>::propagate_on_container_swap::value == true ||
a.get_allocator() == b.get_allocator()
Thus, if the allocators do not propagate on swap and if they do not compare equal, swapping the containers is undefined behaviour in the first place.
Since there's nothing to keep an iterator from keeping a reference or pointer to the original container, I'd say you can't rely on the iterators remaining valid unless you find an explicit guarantee in the standard.
items in std::vector are dynamically allocated and their addresses may change when a reallocation happens. So, it is not possible to depend on their addresses because it is not stable.
On the other hand, if I have a std::vector which contains some items and I do not have any intention to change anything about it during its life cycle, is it valid (well-defined) to use the addresses of its items?
Example:
std::vector<foo> foos;
foos.reserve(100);
for(size_t i=0;i<100;++i){
foos.emplace_back(make_random_foo());
}
//From now no one can touch foos
auto ptr_to_the_fifth_foo=&foos[4];
In other words, does the standard guarantee that noting will affect the vector items addresses since I did not do that by my self?
If no member function of the std::vector is called, the vector may not be changed at all and as such the contents remain the same and all pointers stay valid.
In your example you call operator[](size_type n) which is defined in the standard as being equivalent to *(a.begin() + n).
A std::vector is a container and therefore, the container requirements hold which state:
Unless otherwise specified (either explicitly or by defining a function in terms of other functions), invoking a container member function or passing a container as an argument to a library function shall not invalidate iterators to, or change the values of, objects within that container.
Since begin() is not specified to invalidate any iterators to the container, operator[] won't either.
Yes.
Pointers and references to elements are only invalidated when their iterator is invalidated.
Iterators are invalidated when capacity has to grow (when size passes capacity), or when you insert/remove elements before that element in the vector. They can also be invalidated when a container is moved-to or moved-from, but it might not occur.
I believe swap is specified to not invalidate iterators, but rather make them refer to the "new home" as it where (and hence, the pointers/references to the "new home" in the "new vector") (ie, the buffer ownership changes). Move-assign does not make this promise. I do not remember off the top of my head if move-construct does.
If I have an iterator into vector a, then I move-construct or move-assign vector b from a, does that iterator still point to the same element (now in vector b)? Here's what I mean in code:
#include <vector>
#include <iostream>
int main(int argc, char *argv[])
{
std::vector<int>::iterator a_iter;
std::vector<int> b;
{
std::vector<int> a{1, 2, 3, 4, 5};
a_iter = a.begin() + 2;
b = std::move(a);
}
std::cout << *a_iter << std::endl; // Is a_iter valid here?
return 0;
}
Is a_iter still valid since a has been moved into b, or is the iterator invalidated by the move? For reference, std::vector::swap does not invalidate iterators.
While it might be reasonable to assume that iterators are still valid after a move, I don't think the Standard actually guarantees this. Therefore, the iterators are in an undefined state after the move.
There is no reference I can find in the Standard which specifically states that iterators that existed before a move are still valid after the move.
On the surface, it would seem to be perfectly reasonable to assume that an iterator is typically implemented as pointers in to the controlled sequence. If that's the case, then the iterators would still be valid after the move.
But the implementation of an iterator is implementation-defined. Meaning, so long as the iterator on a particular platform meets the requirements set forth by the Standard, it can be implemented in any way whatsoever. It could, in theory, be implemented as a combination of a pointer back to the vector class along with an index. If that's the case, then the iterators would become invalid after the move.
Whether or not an iterator is actually implemented this way is irrelevant. It could be implemented this way, so without a specific guarantee from the Standard that post-move iterators are still valid, you cannot assume that they are. Bear in mind also that there is such a guarantee for iterators after a swap. This was specifically clarified from the previous Standard. Perhaps it was simply an oversight of the Std comittee to not make a similar clarification for iterators after a move, but in any case there is no such guarantee.
Therefore, the long and the short of it is you can't assume your iterators are still good after a move.
EDIT:
23.2.1/11 in Draft n3242 states that:
Unless otherwise specified (either explicitly or by defining a
function in terms of other functions), invoking a container member
function or passing a container as an argument to a library function
shall not invalidate iterators to, or change the values of, objects
within that container.
This might lead one to conclude that the iterators are valid after a move, but I disagree. In your example code, a_iter was an iterator in to the vector a. After the move, that container, a has certainly been changed. My conclusion is the above clause does not apply in this case.
I think the edit that changed move construction to move assignment changes the answer.
At least if I'm reading table 96 correctly, the complexity for move construction is given as "note B", which is constant complexity for anything except std::array. The complexity for move assignment, however, is given as linear.
As such, the move construction has essentially no choice but to copy the pointer from the source, in which case it's hard to see how the iterators could become invalid.
For move assignment, however, the linear complexity means it could choose to move individual elements from the source to the destination, in which case the iterators will almost certainly become invalid.
The possibility of move assignment of elements is reinforced by the description: "All existing elements of a are either move assigned to or destroyed". The "destroyed" part would correspond to destroying the existing contents, and "stealing" the pointer from the source -- but the "move assigned to" would indicate moving individual elements from source to destination instead.
tl;dr : Yes, moving a std::vector<T, A> possibly invalidates the iterators
The common case (with std::allocator in place) is that invalidation does not happen but there is no guarantee and switching compilers or even the next compiler update might make your code behave incorrect if you rely on the fact the your implementation currently does not invalidate the iterators.
On move assignment:
The question whether std::vector iterators can actually remain valid after move-assignment is connected with the allocator awareness of the vector template and depends on the allocator type (and possibly the respective instances thereof).
In every implementation I have seen, move-assignment of a std::vector<T, std::allocator<T>>1 will not actually invalidate iterators or pointers. There is a problem however, when it comes down to making use of this, as the standard just cannot guarantee that iterators remain valid for any move-assignment of a std::vector instance in general, because the container is allocator aware.
Custom allocators may have state and if they do not propagate on move assignment and do not compare equal, the vector must allocate storage for the moved elements using its own allocator.
Let:
std::vector<T, A> a{/*...*/};
std::vector<T, A> b;
b = std::move(a);
Now if
std::allocator_traits<A>::propagate_on_container_move_assignment::value == false &&
std::allocator_traits<A>::is_always_equal::value == false && (possibly as of c++17)
a.get_allocator() != b.get_allocator()
then b will allocate new storage and move elements of a one by one into that storage, thus invalidating all iterators, pointers and references.
The reason is that fulfillment of above condition 1. forbidds move assignment of the allocator on container move. Therefore, we have to deal with two different instances of the allocator. If those two allocator objects now neither always compare equal (2.) nor actually compare equal, then both allocators have a different state. An allocator x may not be able to deallocate memory of another allocator y having a different state and therefore a container with allocator x cannot just steal memory from a container which allocated its memory via y.
If the allocator propagates on move assignment or if both allocators compare equal, then an implementation will very likely choose to just make b own as data because it can be sure to be able to deallocate the storage properly.
1: std::allocator_traits<std::allocator<T>>::propagate_on_container_move_assignment and std::allocator_traits<std::allocator<T>>::is_always_equal both are typdefs for std::true_type (for any non-specialized std::allocator).
On move construction:
std::vector<T, A> a{/*...*/};
std::vector<T, A> b(std::move(a));
The move constructor of an allocator aware container will move-construct its allocator instance from the allocator instance of the container which the current expression is moving from. Thus, the proper deallocation capability is ensured and the memory can (and in fact will) be stolen because move construction is (except for std::array) bound to have constant complexity.
Note: There is still no guarantee for iterators to remain valid even for move construction.
On swap:
Demanding the iterators of two vectors to remain valid after a swap (now just pointing into the respective swapped container) is easy because swapping only has defined behaviour if
std::allocator_traits<A>::propagate_on_container_swap::value == true ||
a.get_allocator() == b.get_allocator()
Thus, if the allocators do not propagate on swap and if they do not compare equal, swapping the containers is undefined behaviour in the first place.
Since there's nothing to keep an iterator from keeping a reference or pointer to the original container, I'd say you can't rely on the iterators remaining valid unless you find an explicit guarantee in the standard.