Bitwise copy semantics c

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

Yes, RVO still kicks in. Actually, the compiler is expected to pick:

• RVO (if possible)
• Move construction (if possible)
• Copy construction (last resort)

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?

The STL containers are movable, regardless of the types stored within. However, operations on the objects in the container require the object cooperation, and as such sort (for example) may only move objects if those objects are movable.

Do we get benefited by move semantics in below case as integer is a primitive type ?

Yes, you do, because containers are movable regardless of their content. As you deduced, st2 will steal the memory from st1. The state of st1 after the move is unspecified though, so I cannot guarantee its storage will have been nullified.

When a push_back is called using std::move on lvalue [what happens] ?

The move constructor of the type of the lvalue is called, typically this involves a bitwise copy of the original into the destination, and then a nullification of the original.

In general, the cost of a move constructor is proportional to sizeof(object); for example, sizeof(std::string) is stable regardless of how many characters the std::string has, because in effect those characters are stored on the heap (at least when there is a sufficient number of them) and thus only the pointer to the heap storage is moved around (plus some metadata).