What is move semantics in C++?

The problem.

Movement semantics are a tool that comes to the aid of the C++ programmer to solve a performance problem that has been dragging on since the creation of the language, let's see an example of inefficient code:

std::string Quijote("En un lugar de La Mancha de cuyo nombre no quiero acordarme ...");
// Continua durante centenares de miles de caracteres -------------------------> ~~~

std::string TO_UPPER(std::string in)
{
    std::transform(in.begin(), in.end(), in.begin(), std::toupper);
    return in;
}

int main()
{
    std::cout << TO_UPPER(Quijote);
    return 0;
}

TO_UPPERWhen you call copy the variable Quijoteto the local variable of the function in, this copy is processed and then the processed copy is returned and it is copied again .

Before move semantics in C++ we could use references to solve the above problem:

std::string Quijote("En un lugar de La Mancha de cuyo nombre no quiero acordarme ...");
// Continua durante centenares de miles de caracteres -------------------------> ~~~

//          v------- referencia
std::string &TO_UPPER(std::string &in)
// referencia --------------------^
{
    std::transform(in.begin(), in.end(), in.begin(), std::toupper);
    return in;
}

int main()
{
    std::cout << TO_UPPER(Quijote);
    return 0;
}

Using references avoids making unnecessary copies of variables and improves code performance. But references don't solve all problems:

std::vector<std::string> &read_table(std::string table)
{
    std::vector<std::string> result;
    // fill result...
    return result;
}

int main()
{
    auto customers = read_table("customers");
    return 0;
}

In the above code we have a dangling reference since resultthe function's internal variable read_tableceases to exist the moment the function is exited and therefore using it outside the function will cause errors... so we return to the handy references :

//                                  referencia -------------v
void read_table(std::string table, std::vector<std::string> &result)
{
    // fill result...
}

int main()
{
    std::vector<std::string> customers;
    read_table("customers", customers);
    return 0;
}

The solution.

Imagine that instead of copying data from one function to another we could move this data, that's the semantics of movement.

The semantics of movement are supported by " Reference to Right Value " (RvD), which allow referencing temporary values, which was impossible before C++11.

Right Value References use the declarator &&(in declaration context it corresponds to " Right Value Reference " in expression it is the logical AND operator ).

But what is an RvD ?, a Right Value is everything that has the capacity to be to the right of an expression and generally a temporary value, all the following expressions to the right of it =are temporary Right Values:

const float PI          = 3.14159265359f;
float sqrPi             = std::sqrt(PI);
auto t                  = std::time(nullptr);
auto f                  = t & 1? PI : sqrPi;
std::string hocus_pocus = "Hocus Pocus!";
auto lorem_ipsum        = std::string("Lorem Ipsum!");

Before C++11 you couldn't reference Right Values, but by adding the move semantics these values ​​are referable and functions can be overloaded to accept them:

std::string hocus_pocus = "Hocus Pocus!";

/* 1 */ void f(std::string &s);  // Funcion que recibe una referencia normal.
/* 2 */ void f(std::string &&s); // Funcion que recibe una RvD.

f(hocus_pocus);                // Llama a la primera sobrecarga.
f("Hocus Pocus!");             // Llama a la segunda sobrecarga.
f(std::string("Lorem Ipsum!"); // Llama a la segunda sobrecarga.

For objects that handle resources, when they receive a temporary value (a value that we know is going to be removed after evaluating the expression) we can decide to swap the resource from the temporary to avoid more expensive operations:

Free motion semantics!

The standard library adapts all of its constructs from C++11 to take advantage of move semantics, so by switching to a C++11 or higher compiler we get these semantics without changing the code. This usually implies a performance improvement just by recompiling!

So now we can fix the problems we had before:

// Referencia a Valor Derecho ---vv
std::string TO_UPPER(std::string &&in)
{
    std::transform(in.begin(), in.end(), in.begin(), std::toupper);
    return std::move(in);
 // ~~~~~~~~~~~~~~~~~~~~ <----- mover el valor fuera de la función.
}

Since the std::stringC++11 template incorporates move semantics, when we call the function TO_UPPERwith temporary values, the values ​​will be moved saving unnecessary copies. The function std::movetransforms a value to RvD, so going back to the overloaded function example:

std::string hocus_pocus = "Hocus Pocus!";

/* 1 */ void f(std::string &s);  // Funcion que recibe una referencia normal.
/* 2 */ void f(std::string &&s); // Funcion que recibe una RvD.

f(hocus_pocus);                 // Llama a la primera sobrecarga.
f("Hocus Pocus!");              // Llama a la segunda sobrecarga.
f(std::string("Lorem Ipsum!")); // Llama a la segunda sobrecarga.
f(std::move(hocus_pocus));      // Llama a la SEGUNDA sobrecarga.

It is important to note that std::move, despite receiving the name move , it does not move anything, it only transforms a variable to RvD, so this instruction does not move anything anywhere:

std::string hocus_pocus = "Hocus Pocus!";

std::move(hocus_pocus); // Esto NO HACE NADA de nada.

What happens to what I move?

As we have seen, it std::movetransforms from reference ( &) to RvD ( &&) and it is actually the instruction or constructor that receives said RvD that performs the movement operation, but what about the moved objects?

std::string hocus_pocus = "Hocus Pocus!"; // Crear objeto

void f(std::string &&s);

f(std::move(hocus_pocus)); // Mover objeto dentro de funcion...

std::cout << hocus_pocus; // Que contiene ahora hocus_pocus?

According to the C++ standard , moved objects are valid even though their content is indeterminate (translation and emphasis mine):

7.6.5.15 Status of moved library types

Objects with types defined in the C++ Standard Library can be moved. Move operations can be generated explicitly or implicitly. Unless otherwise stated, these moved objects will be set to a valid but undetermined state .

Not all that glitters is gold.

As almost every time a new feature is added, incorrect uses of it arise, it is not convenient to abuse std::moveit since it can lead to a worsening of performance by preventing the compiler from applying optimizations, for example the following code has a problem:

std::string Publicar_Quijote()
{
    std::string Quijote("En un lugar de La Mancha de ..."
    return std::move(Quijote);
}

According to the C++ standard (translation and highlighting mine):

« 12.8, 31.1 and 31.3 Copy and move objects »

In a statement returnin a function, when the expression is the name of an object, the copy/move operation can be bypassed by constructing the object directly on the return value of the function .

When a temporary object can be copied/moved, the copy/move operation can be bypassed by constructing the temporary object directly on the destination of the copied/moved object .

So it's a good idea not to abuse calls std::moveas they avoid these compiler optimizations known as "Return Value Optimization" (OvR) ( RVO in English ). It is worth noting that OvR exists in C++ before C++11 and does not require any action on the part of the programmer to take advantage of it.

More information.

You can see this explanation of the semantics of movement in this video (video in Spanish, text in English).