Move semantics clarification

Question

I have read the below post which gives a very good insight into move semantics:

Can someone please explain move semantics to me?

but I am still fail to understand following things regarding move semantics -

1. Does copy elision and RVO would still work for classes without move constructors?

2. Even if our classes doesn't have move constructors, but STL containers has one. For operation like

std::vector vt = CreateMyClassVector();

and to perform operations like sorting etc. Why can't STL internally leverage move semantics to improve such operations internally using operations like copy elision or RVO which doesn't require move constructors?

3. Do we get benefited by move semantics in below case -

std::vector< int > vt1(1000000, 5); // Create and initialize 1 million entries with value 5

std::vector< int > vt2(std::move(vt1)); // move vt1 to vt2

as integer is a primitive type, moving integer elements will not offer any advantage. or here after move operation vt2 simply points to vt1 memory in heap and vt1 is set to null. what is actually happening? If latter is the case then even point 2 holds that we may not need move constructor for our classes.

4. When a push_back() is called using std::move on lvalue for e.g :

    std::vector<MyClass> vt;

    for(int i=0; i<10; ++i)
    {
        vt.push_back(MyClass());
    }

    MyClass obj;

    vt.push_back(std::move(obj));

now as vector has contiguous memory allocation, and obj is defined somewhere else in memory how would move semantics move the obj memory to vector vt contiguous memory region, wouldn't moving memory in this case is as good as copying memory, how does move justifies vectors contiguous memory requirements by simply moving a pointer pointing to a memory in different region of a heap.?

Thanks for explanation in advance! [EDITED the question as requested.]

Answer 1

Most semantics is not a way of moving memory. It's all about the transference of ownership of objects from one object instance to another. When you do this:

std::string str1("Some string.");
std::string str2(std::move(str1));

std::string allocates and manages a buffer of characters. Therefore, each std::string owns a buffer of memory, which contains the string itself.

The move constructor called to construct str2 will take the character buffer allocated by str1 and remove it from that object. Thus str2 now has the pointer that str1 originally allocated, and str1 doesn't have that pointer anymore. That's what move semantics is all about: transferring ownership of memory owned by an object.

If your class does not have a move constructor, std::vector will not call it. Obviously. Therefore, it cannot take advantage of any potential optimizations that having a move constructor might bring. But these optimization opportunities only exist for objects which have value semantics and which contain resources that must be managed. Otherwise, movement doesn't help you.

The general rule is to use smart pointers and container objects like vector, string, and the like to avoid having to write move constructors at all. Thus, (if your compiler properly supports generating move constructors) resource management happens automatically.