How do vector elements preserve their original address after a vector std::move?












6














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 <------|









share|improve this question





























    6














    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 <------|









    share|improve this question



























      6












      6








      6







      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 <------|









      share|improve this question















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 24 at 5:02









      Boann

      36.7k1287121




      36.7k1287121










      asked Dec 23 at 15:25









      Vassilis

      1,53712136




      1,53712136
























          3 Answers
          3






          active

          oldest

          votes


















          11














          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.






          share|improve this answer

















          • 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










          • @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





















          1














          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.






          share|improve this answer





















          • 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. 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





















          0














          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.






          share|improve this answer





















            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
            });


            }
            });














            draft saved

            draft discarded


















            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









            11














            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.






            share|improve this answer

















            • 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










            • @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


















            11














            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.






            share|improve this answer

















            • 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










            • @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
















            11












            11








            11






            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.






            share|improve this answer












            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Dec 23 at 15:34









            Some programmer dude

            294k24248410




            294k24248410








            • 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










            • @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




              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










            • 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















            1














            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.






            share|improve this answer





















            • 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. 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


















            1














            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.






            share|improve this answer





















            • 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. 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
















            1












            1








            1






            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.






            share|improve this answer












            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            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. 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




















            • 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. 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


















            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













            0














            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.






            share|improve this answer


























              0














              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.






              share|improve this answer
























                0












                0








                0






                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.






                share|improve this answer












                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.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Dec 23 at 15:32









                Sergey

                4,98423056




                4,98423056






























                    draft saved

                    draft discarded




















































                    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.




                    draft saved


                    draft discarded














                    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





















































                    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







                    Popular posts from this blog

                    數位音樂下載

                    格利澤436b

                    When can things happen in Etherscan, such as the picture below?