How do vector elements preserve their original address after a vector std::move?
As you can see in the output, the objects of the vector pre
not only "moved" to the vector post
, but also preserved their original address space in memory. What is really going on behind this move? Is this behaviour expected? Say I need to have a separate vector of pointers to these objects, is it safe to assume that after this move the objects will always have their original addresses?
Actually, I have a class containing a vector like this and the vector of pointers I mentioned as members. I have also deleted the copy ctors, and defined the move ones for the class.
#include <iostream>
#include <vector>
struct B {
int val = 0;
B(int aInt) : val(aInt) { };
};
int main() {
std::vector<B> pre;
pre.push_back(B(1));
pre.push_back(B(2));
std::cout << "pre-move:t" << (void*)&pre.at(0) << 'n';
std::cout << "pre-move:t" << (void*)&pre.at(1) << 'n';
std::vector<B> post(std::move(pre));
std::cout << "post-move:t" << (void*)&post.at(0) << 'n';
std::cout << "post-move:t" << (void*)&post.at(1) << 'n';
return 0;
}
Output:
pre-move: 0x1d7b150
pre-move: 0x1d7b154 <------|
post-move: 0x1d7b150 |
post-move: 0x1d7b154 <------|
c++ c++11 vector move-semantics
add a comment |
As you can see in the output, the objects of the vector pre
not only "moved" to the vector post
, but also preserved their original address space in memory. What is really going on behind this move? Is this behaviour expected? Say I need to have a separate vector of pointers to these objects, is it safe to assume that after this move the objects will always have their original addresses?
Actually, I have a class containing a vector like this and the vector of pointers I mentioned as members. I have also deleted the copy ctors, and defined the move ones for the class.
#include <iostream>
#include <vector>
struct B {
int val = 0;
B(int aInt) : val(aInt) { };
};
int main() {
std::vector<B> pre;
pre.push_back(B(1));
pre.push_back(B(2));
std::cout << "pre-move:t" << (void*)&pre.at(0) << 'n';
std::cout << "pre-move:t" << (void*)&pre.at(1) << 'n';
std::vector<B> post(std::move(pre));
std::cout << "post-move:t" << (void*)&post.at(0) << 'n';
std::cout << "post-move:t" << (void*)&post.at(1) << 'n';
return 0;
}
Output:
pre-move: 0x1d7b150
pre-move: 0x1d7b154 <------|
post-move: 0x1d7b150 |
post-move: 0x1d7b154 <------|
c++ c++11 vector move-semantics
add a comment |
As you can see in the output, the objects of the vector pre
not only "moved" to the vector post
, but also preserved their original address space in memory. What is really going on behind this move? Is this behaviour expected? Say I need to have a separate vector of pointers to these objects, is it safe to assume that after this move the objects will always have their original addresses?
Actually, I have a class containing a vector like this and the vector of pointers I mentioned as members. I have also deleted the copy ctors, and defined the move ones for the class.
#include <iostream>
#include <vector>
struct B {
int val = 0;
B(int aInt) : val(aInt) { };
};
int main() {
std::vector<B> pre;
pre.push_back(B(1));
pre.push_back(B(2));
std::cout << "pre-move:t" << (void*)&pre.at(0) << 'n';
std::cout << "pre-move:t" << (void*)&pre.at(1) << 'n';
std::vector<B> post(std::move(pre));
std::cout << "post-move:t" << (void*)&post.at(0) << 'n';
std::cout << "post-move:t" << (void*)&post.at(1) << 'n';
return 0;
}
Output:
pre-move: 0x1d7b150
pre-move: 0x1d7b154 <------|
post-move: 0x1d7b150 |
post-move: 0x1d7b154 <------|
c++ c++11 vector move-semantics
As you can see in the output, the objects of the vector pre
not only "moved" to the vector post
, but also preserved their original address space in memory. What is really going on behind this move? Is this behaviour expected? Say I need to have a separate vector of pointers to these objects, is it safe to assume that after this move the objects will always have their original addresses?
Actually, I have a class containing a vector like this and the vector of pointers I mentioned as members. I have also deleted the copy ctors, and defined the move ones for the class.
#include <iostream>
#include <vector>
struct B {
int val = 0;
B(int aInt) : val(aInt) { };
};
int main() {
std::vector<B> pre;
pre.push_back(B(1));
pre.push_back(B(2));
std::cout << "pre-move:t" << (void*)&pre.at(0) << 'n';
std::cout << "pre-move:t" << (void*)&pre.at(1) << 'n';
std::vector<B> post(std::move(pre));
std::cout << "post-move:t" << (void*)&post.at(0) << 'n';
std::cout << "post-move:t" << (void*)&post.at(1) << 'n';
return 0;
}
Output:
pre-move: 0x1d7b150
pre-move: 0x1d7b154 <------|
post-move: 0x1d7b150 |
post-move: 0x1d7b154 <------|
c++ c++11 vector move-semantics
c++ c++11 vector move-semantics
edited Dec 24 at 5:02
Boann
36.7k1287121
36.7k1287121
asked Dec 23 at 15:25
Vassilis
1,53712136
1,53712136
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
A vector is basically nothing more than a pointer to heap-allocated memory, the current length and the current capacity of the vector.
By "moving" a vector, all you're doing is copying those values, and resetting the values of the moved-from vector.
For the data of the vector, it's basically equivalent to
original_pointer = some_place_in_memory;
new_pointer = original_pointer; // Copies the *value* of original_pointer
original_pointer = nullptr;
There's no need to allocate new memory and copy the data in the vector.
2
When usingpush_back
though, to add an element to a vector, all elements' addresses do change! Is this due to the vector's design to have its elements contiguously in memory, thus it copies them to another (bigger) address space?
– Vassilis
Dec 23 at 15:43
@Vassilis Yes that's correct. If adding an element will make the size exceed the capacity, then the data have to be reallocated to a new and larger memory area. This is the reason that pointers and iterators to elements can become invalidated.
– Some programmer dude
Dec 23 at 16:19
Can it be relied upon that iterators and pointers remain valid (albeit in the moved to object)?
– Galik
Dec 23 at 16:34
3
Looking at the manual it apparently can be relied upon unless the source and destination have different allocators in which case all elements are moved individually: en.cppreference.com/w/cpp/container/vector/operator%3D It may be worth adding this information as it is part of the question.
– Galik
Dec 23 at 16:39
@Galik, maybe you mean this, which refers to constructors instead. Indeed 6 and 7 mention that when a custom allocator is used, an element-wise move will take place so the pointers to the original objects will be invalid.
– Vassilis
Dec 23 at 17:13
add a comment |
The whole point of the move operation is to avoid copying the elements, so if they got copied(there is no such thing as truly "moving" the memory) the move would be just a copy.
Vectors are usually implemented as 3 pointers: begin,end and capacity. All point to a dynamically-allocated array. Then moving the vector is just copying those three pointers and so the array and elements just change their owner.
I think it should be safe to assume that pointers to the elements remain valid.
Why would capacity be a pointer? I thought it's a size_t variable.
– Michael Mahn
Dec 23 at 17:24
2
@MichaelMahn It could be either. InGCC
at least it is a pointer. If you think about it a pointer makes sense because pointers are iterators and it is easier to use standard algorithms on two iterators than it is on one iterator and an offset.
– Galik
Dec 23 at 17:38
add a comment |
It will be clear, if we write semantically equal code without std::vector
:
B* pre = new B[2]; // Declare std::vector<B> and allocate some space to make the following line correct
B[0] = 1; // pre.push_back(B(1));
B[1] = 2; // pre.push_back(B(2));
B* post = pre; // std::vector<B> post(std::move(pre));
Actually, vector move boils down to pointer copying without reallocation. Data which the pointer points at remains in it's place, so addresses of vector elements do not change.
In this code example after the fourth line, both pre
and post
point to the same data with same address.
std::vector
is a wrapper for a pointer to array with some additional functionality. So after doing std::vector<B> post(std::move(pre));
, post
will contain a pointer with the same value which was in pre
.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53904835%2fhow-do-vector-elements-preserve-their-original-address-after-a-vector-stdmove%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
A vector is basically nothing more than a pointer to heap-allocated memory, the current length and the current capacity of the vector.
By "moving" a vector, all you're doing is copying those values, and resetting the values of the moved-from vector.
For the data of the vector, it's basically equivalent to
original_pointer = some_place_in_memory;
new_pointer = original_pointer; // Copies the *value* of original_pointer
original_pointer = nullptr;
There's no need to allocate new memory and copy the data in the vector.
2
When usingpush_back
though, to add an element to a vector, all elements' addresses do change! Is this due to the vector's design to have its elements contiguously in memory, thus it copies them to another (bigger) address space?
– Vassilis
Dec 23 at 15:43
@Vassilis Yes that's correct. If adding an element will make the size exceed the capacity, then the data have to be reallocated to a new and larger memory area. This is the reason that pointers and iterators to elements can become invalidated.
– Some programmer dude
Dec 23 at 16:19
Can it be relied upon that iterators and pointers remain valid (albeit in the moved to object)?
– Galik
Dec 23 at 16:34
3
Looking at the manual it apparently can be relied upon unless the source and destination have different allocators in which case all elements are moved individually: en.cppreference.com/w/cpp/container/vector/operator%3D It may be worth adding this information as it is part of the question.
– Galik
Dec 23 at 16:39
@Galik, maybe you mean this, which refers to constructors instead. Indeed 6 and 7 mention that when a custom allocator is used, an element-wise move will take place so the pointers to the original objects will be invalid.
– Vassilis
Dec 23 at 17:13
add a comment |
A vector is basically nothing more than a pointer to heap-allocated memory, the current length and the current capacity of the vector.
By "moving" a vector, all you're doing is copying those values, and resetting the values of the moved-from vector.
For the data of the vector, it's basically equivalent to
original_pointer = some_place_in_memory;
new_pointer = original_pointer; // Copies the *value* of original_pointer
original_pointer = nullptr;
There's no need to allocate new memory and copy the data in the vector.
2
When usingpush_back
though, to add an element to a vector, all elements' addresses do change! Is this due to the vector's design to have its elements contiguously in memory, thus it copies them to another (bigger) address space?
– Vassilis
Dec 23 at 15:43
@Vassilis Yes that's correct. If adding an element will make the size exceed the capacity, then the data have to be reallocated to a new and larger memory area. This is the reason that pointers and iterators to elements can become invalidated.
– Some programmer dude
Dec 23 at 16:19
Can it be relied upon that iterators and pointers remain valid (albeit in the moved to object)?
– Galik
Dec 23 at 16:34
3
Looking at the manual it apparently can be relied upon unless the source and destination have different allocators in which case all elements are moved individually: en.cppreference.com/w/cpp/container/vector/operator%3D It may be worth adding this information as it is part of the question.
– Galik
Dec 23 at 16:39
@Galik, maybe you mean this, which refers to constructors instead. Indeed 6 and 7 mention that when a custom allocator is used, an element-wise move will take place so the pointers to the original objects will be invalid.
– Vassilis
Dec 23 at 17:13
add a comment |
A vector is basically nothing more than a pointer to heap-allocated memory, the current length and the current capacity of the vector.
By "moving" a vector, all you're doing is copying those values, and resetting the values of the moved-from vector.
For the data of the vector, it's basically equivalent to
original_pointer = some_place_in_memory;
new_pointer = original_pointer; // Copies the *value* of original_pointer
original_pointer = nullptr;
There's no need to allocate new memory and copy the data in the vector.
A vector is basically nothing more than a pointer to heap-allocated memory, the current length and the current capacity of the vector.
By "moving" a vector, all you're doing is copying those values, and resetting the values of the moved-from vector.
For the data of the vector, it's basically equivalent to
original_pointer = some_place_in_memory;
new_pointer = original_pointer; // Copies the *value* of original_pointer
original_pointer = nullptr;
There's no need to allocate new memory and copy the data in the vector.
answered Dec 23 at 15:34
Some programmer dude
294k24248410
294k24248410
2
When usingpush_back
though, to add an element to a vector, all elements' addresses do change! Is this due to the vector's design to have its elements contiguously in memory, thus it copies them to another (bigger) address space?
– Vassilis
Dec 23 at 15:43
@Vassilis Yes that's correct. If adding an element will make the size exceed the capacity, then the data have to be reallocated to a new and larger memory area. This is the reason that pointers and iterators to elements can become invalidated.
– Some programmer dude
Dec 23 at 16:19
Can it be relied upon that iterators and pointers remain valid (albeit in the moved to object)?
– Galik
Dec 23 at 16:34
3
Looking at the manual it apparently can be relied upon unless the source and destination have different allocators in which case all elements are moved individually: en.cppreference.com/w/cpp/container/vector/operator%3D It may be worth adding this information as it is part of the question.
– Galik
Dec 23 at 16:39
@Galik, maybe you mean this, which refers to constructors instead. Indeed 6 and 7 mention that when a custom allocator is used, an element-wise move will take place so the pointers to the original objects will be invalid.
– Vassilis
Dec 23 at 17:13
add a comment |
2
When usingpush_back
though, to add an element to a vector, all elements' addresses do change! Is this due to the vector's design to have its elements contiguously in memory, thus it copies them to another (bigger) address space?
– Vassilis
Dec 23 at 15:43
@Vassilis Yes that's correct. If adding an element will make the size exceed the capacity, then the data have to be reallocated to a new and larger memory area. This is the reason that pointers and iterators to elements can become invalidated.
– Some programmer dude
Dec 23 at 16:19
Can it be relied upon that iterators and pointers remain valid (albeit in the moved to object)?
– Galik
Dec 23 at 16:34
3
Looking at the manual it apparently can be relied upon unless the source and destination have different allocators in which case all elements are moved individually: en.cppreference.com/w/cpp/container/vector/operator%3D It may be worth adding this information as it is part of the question.
– Galik
Dec 23 at 16:39
@Galik, maybe you mean this, which refers to constructors instead. Indeed 6 and 7 mention that when a custom allocator is used, an element-wise move will take place so the pointers to the original objects will be invalid.
– Vassilis
Dec 23 at 17:13
2
2
When using
push_back
though, to add an element to a vector, all elements' addresses do change! Is this due to the vector's design to have its elements contiguously in memory, thus it copies them to another (bigger) address space?– Vassilis
Dec 23 at 15:43
When using
push_back
though, to add an element to a vector, all elements' addresses do change! Is this due to the vector's design to have its elements contiguously in memory, thus it copies them to another (bigger) address space?– Vassilis
Dec 23 at 15:43
@Vassilis Yes that's correct. If adding an element will make the size exceed the capacity, then the data have to be reallocated to a new and larger memory area. This is the reason that pointers and iterators to elements can become invalidated.
– Some programmer dude
Dec 23 at 16:19
@Vassilis Yes that's correct. If adding an element will make the size exceed the capacity, then the data have to be reallocated to a new and larger memory area. This is the reason that pointers and iterators to elements can become invalidated.
– Some programmer dude
Dec 23 at 16:19
Can it be relied upon that iterators and pointers remain valid (albeit in the moved to object)?
– Galik
Dec 23 at 16:34
Can it be relied upon that iterators and pointers remain valid (albeit in the moved to object)?
– Galik
Dec 23 at 16:34
3
3
Looking at the manual it apparently can be relied upon unless the source and destination have different allocators in which case all elements are moved individually: en.cppreference.com/w/cpp/container/vector/operator%3D It may be worth adding this information as it is part of the question.
– Galik
Dec 23 at 16:39
Looking at the manual it apparently can be relied upon unless the source and destination have different allocators in which case all elements are moved individually: en.cppreference.com/w/cpp/container/vector/operator%3D It may be worth adding this information as it is part of the question.
– Galik
Dec 23 at 16:39
@Galik, maybe you mean this, which refers to constructors instead. Indeed 6 and 7 mention that when a custom allocator is used, an element-wise move will take place so the pointers to the original objects will be invalid.
– Vassilis
Dec 23 at 17:13
@Galik, maybe you mean this, which refers to constructors instead. Indeed 6 and 7 mention that when a custom allocator is used, an element-wise move will take place so the pointers to the original objects will be invalid.
– Vassilis
Dec 23 at 17:13
add a comment |
The whole point of the move operation is to avoid copying the elements, so if they got copied(there is no such thing as truly "moving" the memory) the move would be just a copy.
Vectors are usually implemented as 3 pointers: begin,end and capacity. All point to a dynamically-allocated array. Then moving the vector is just copying those three pointers and so the array and elements just change their owner.
I think it should be safe to assume that pointers to the elements remain valid.
Why would capacity be a pointer? I thought it's a size_t variable.
– Michael Mahn
Dec 23 at 17:24
2
@MichaelMahn It could be either. InGCC
at least it is a pointer. If you think about it a pointer makes sense because pointers are iterators and it is easier to use standard algorithms on two iterators than it is on one iterator and an offset.
– Galik
Dec 23 at 17:38
add a comment |
The whole point of the move operation is to avoid copying the elements, so if they got copied(there is no such thing as truly "moving" the memory) the move would be just a copy.
Vectors are usually implemented as 3 pointers: begin,end and capacity. All point to a dynamically-allocated array. Then moving the vector is just copying those three pointers and so the array and elements just change their owner.
I think it should be safe to assume that pointers to the elements remain valid.
Why would capacity be a pointer? I thought it's a size_t variable.
– Michael Mahn
Dec 23 at 17:24
2
@MichaelMahn It could be either. InGCC
at least it is a pointer. If you think about it a pointer makes sense because pointers are iterators and it is easier to use standard algorithms on two iterators than it is on one iterator and an offset.
– Galik
Dec 23 at 17:38
add a comment |
The whole point of the move operation is to avoid copying the elements, so if they got copied(there is no such thing as truly "moving" the memory) the move would be just a copy.
Vectors are usually implemented as 3 pointers: begin,end and capacity. All point to a dynamically-allocated array. Then moving the vector is just copying those three pointers and so the array and elements just change their owner.
I think it should be safe to assume that pointers to the elements remain valid.
The whole point of the move operation is to avoid copying the elements, so if they got copied(there is no such thing as truly "moving" the memory) the move would be just a copy.
Vectors are usually implemented as 3 pointers: begin,end and capacity. All point to a dynamically-allocated array. Then moving the vector is just copying those three pointers and so the array and elements just change their owner.
I think it should be safe to assume that pointers to the elements remain valid.
answered Dec 23 at 15:34
Quimby
55719
55719
Why would capacity be a pointer? I thought it's a size_t variable.
– Michael Mahn
Dec 23 at 17:24
2
@MichaelMahn It could be either. InGCC
at least it is a pointer. If you think about it a pointer makes sense because pointers are iterators and it is easier to use standard algorithms on two iterators than it is on one iterator and an offset.
– Galik
Dec 23 at 17:38
add a comment |
Why would capacity be a pointer? I thought it's a size_t variable.
– Michael Mahn
Dec 23 at 17:24
2
@MichaelMahn It could be either. InGCC
at least it is a pointer. If you think about it a pointer makes sense because pointers are iterators and it is easier to use standard algorithms on two iterators than it is on one iterator and an offset.
– Galik
Dec 23 at 17:38
Why would capacity be a pointer? I thought it's a size_t variable.
– Michael Mahn
Dec 23 at 17:24
Why would capacity be a pointer? I thought it's a size_t variable.
– Michael Mahn
Dec 23 at 17:24
2
2
@MichaelMahn It could be either. In
GCC
at least it is a pointer. If you think about it a pointer makes sense because pointers are iterators and it is easier to use standard algorithms on two iterators than it is on one iterator and an offset.– Galik
Dec 23 at 17:38
@MichaelMahn It could be either. In
GCC
at least it is a pointer. If you think about it a pointer makes sense because pointers are iterators and it is easier to use standard algorithms on two iterators than it is on one iterator and an offset.– Galik
Dec 23 at 17:38
add a comment |
It will be clear, if we write semantically equal code without std::vector
:
B* pre = new B[2]; // Declare std::vector<B> and allocate some space to make the following line correct
B[0] = 1; // pre.push_back(B(1));
B[1] = 2; // pre.push_back(B(2));
B* post = pre; // std::vector<B> post(std::move(pre));
Actually, vector move boils down to pointer copying without reallocation. Data which the pointer points at remains in it's place, so addresses of vector elements do not change.
In this code example after the fourth line, both pre
and post
point to the same data with same address.
std::vector
is a wrapper for a pointer to array with some additional functionality. So after doing std::vector<B> post(std::move(pre));
, post
will contain a pointer with the same value which was in pre
.
add a comment |
It will be clear, if we write semantically equal code without std::vector
:
B* pre = new B[2]; // Declare std::vector<B> and allocate some space to make the following line correct
B[0] = 1; // pre.push_back(B(1));
B[1] = 2; // pre.push_back(B(2));
B* post = pre; // std::vector<B> post(std::move(pre));
Actually, vector move boils down to pointer copying without reallocation. Data which the pointer points at remains in it's place, so addresses of vector elements do not change.
In this code example after the fourth line, both pre
and post
point to the same data with same address.
std::vector
is a wrapper for a pointer to array with some additional functionality. So after doing std::vector<B> post(std::move(pre));
, post
will contain a pointer with the same value which was in pre
.
add a comment |
It will be clear, if we write semantically equal code without std::vector
:
B* pre = new B[2]; // Declare std::vector<B> and allocate some space to make the following line correct
B[0] = 1; // pre.push_back(B(1));
B[1] = 2; // pre.push_back(B(2));
B* post = pre; // std::vector<B> post(std::move(pre));
Actually, vector move boils down to pointer copying without reallocation. Data which the pointer points at remains in it's place, so addresses of vector elements do not change.
In this code example after the fourth line, both pre
and post
point to the same data with same address.
std::vector
is a wrapper for a pointer to array with some additional functionality. So after doing std::vector<B> post(std::move(pre));
, post
will contain a pointer with the same value which was in pre
.
It will be clear, if we write semantically equal code without std::vector
:
B* pre = new B[2]; // Declare std::vector<B> and allocate some space to make the following line correct
B[0] = 1; // pre.push_back(B(1));
B[1] = 2; // pre.push_back(B(2));
B* post = pre; // std::vector<B> post(std::move(pre));
Actually, vector move boils down to pointer copying without reallocation. Data which the pointer points at remains in it's place, so addresses of vector elements do not change.
In this code example after the fourth line, both pre
and post
point to the same data with same address.
std::vector
is a wrapper for a pointer to array with some additional functionality. So after doing std::vector<B> post(std::move(pre));
, post
will contain a pointer with the same value which was in pre
.
answered Dec 23 at 15:32
Sergey
4,98423056
4,98423056
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53904835%2fhow-do-vector-elements-preserve-their-original-address-after-a-vector-stdmove%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown