C++11 rvalues et la sémantique de déplacement de la confusion (return)

Premier exemple

std::vector<int> return_vector(void)
{
    std::vector<int> tmp {1,2,3,4,5};
    return tmp;
}

std::vector<int> &&rval_ref = return_vector();

Le premier exemple renvoie une temporaire qui est capturé par rval_ref. Que temporaire aura sa durée de vie prolongée au-delà de la rval_ref définition et vous pouvez l'utiliser comme si vous aviez pris par valeur. Ceci est très similaire à la suivante:

const std::vector<int>& rval_ref = return_vector();

sauf que dans mon réécriture de toute évidence vous ne pouvez pas utiliser rval_ref dans un non-const manière.

Deuxième exemple

std::vector<int>&& return_vector(void)
{
    std::vector<int> tmp {1,2,3,4,5};
    return std::move(tmp);
}

std::vector<int> &&rval_ref = return_vector();

Dans le deuxième exemple, vous avez créé une erreur d'exécution. rval_ref détient désormais une référence pour l'été détruits tmp l'intérieur de la fonction. Avec un peu de chance, ce code serait immédiatement crash.

Troisième exemple

std::vector<int> return_vector(void)
{
    std::vector<int> tmp {1,2,3,4,5};
    return std::move(tmp);
}

std::vector<int> &&rval_ref = return_vector();

Votre troisième exemple est à peu près équivalent à votre premier. Le std::move sur tmp est inutile et peut en fait être une performance pessimization qu'il va inhiber la valeur de retour d'optimisation.

Le meilleur moyen de code de ce que vous faites est:

Meilleures pratiques

std::vector<int> return_vector(void)
{
    std::vector<int> tmp {1,2,3,4,5};
    return tmp;
}

std::vector<int> rval_ref = return_vector();

I. e. tout comme vous le feriez en C++03. tmp est implicitement traitée comme une rvalue dans l'instruction de retour. Il vous sera retourné par retour de valeur-de l'optimisation (pas de copie, pas de déplacement), ou si le compilateur décide qu'il ne peut pas effectuer RVO, puis il sera l'utilisation du vecteur constructeur de déplacement pour faire le retour. Seulement si RVO n'est pas effectuée, et si le retour n'a pas un constructeur de déplacement serait le constructeur de copie être utilisée pour le retour.

La réponse est simple, vous devez écrire du code pour les références rvalue comme vous le feriez régulièrement des références de code, et vous devez les traiter de la même mentalement 99% du temps. Cela comprend toutes les anciennes règles sur le retour de références (c'est à dire de ne jamais retourner une référence à une variable locale).

À moins que vous écrivez un modèle de classe conteneur, qui doit profiter de std::forward et être capable d'écrire une fonction générique qui prend soit lvalue ou références rvalue, c'est plus ou moins vrai.

Un des gros avantages pour le constructeur de déplacement et d'assignation de déplacement, c'est que si vous les définissez, le compilateur peut utiliser dans les cas ont été RVO (valeur de retour d'optimisation) et NRVO (nommé en valeur de retour d'optimisation) ne parviennent pas à être invoquée. C'est assez énorme pour le retour des objets coûteux comme des conteneurs & chaînes par valeur efficace de méthodes.

Maintenant là où les choses deviennent intéressantes, avec des références rvalue, c'est que vous pouvez également les utiliser comme arguments des fonctions normales. Cela permet d'écrire des conteneurs qui ont des surcharges pour les deux const référence (const foo& autre) et de la référence rvalue (foo&& autre). Même si l'argument est trop lourd pour passer avec un simple appel de constructeur il peut encore être fait:

std::vector vec;
for(int x=0; x<10; ++x)
{
    //automatically uses rvalue reference constructor if available
    //because MyCheapType is an unamed temporary variable
    vec.push_back(MyCheapType(0.f));
}


std::vector vec;
for(int x=0; x<10; ++x)
{
    MyExpensiveType temp(1.0, 3.0);
    temp.initSomeOtherFields(malloc(5000));

    //old way, passed via const reference, expensive copy
    vec.push_back(temp);

    //new way, passed via rvalue reference, cheap move
    //just don't use temp again,  not difficult in a loop like this though . . .
    vec.push_back(std::move(temp));
}

Les conteneurs STL ont été mise à jour pour déplacer les surcharges pour presque rien (clé de hachage et des valeurs, vecteur d'insertion, etc), et c'est là que vous verrez le plus.

Vous pouvez également les utiliser pour les fonctions normales, et si vous n'en fournissez une référence rvalue argument, vous pouvez forcer l'appelant à créer l'objet et de laisser la fonction de faire le déplacement. C'est plus un exemple qu'un très bon usage, mais dans ma bibliothèque de rendu, j'ai attribué une chaîne à tous les chargés de ressources, de sorte qu'il est plus facile pour voir ce que chaque objet représente dans le débogueur. L'interface est quelque chose comme ceci:

TextureHandle CreateTexture(int width, int height, ETextureFormat fmt, string&& friendlyName)
{
    std::unique_ptr<TextureObject> tex = D3DCreateTexture(width, height, fmt);
    tex->friendlyName = std::move(friendlyName);
    return tex;
}

C'est une forme de "abstraction qui fuit", mais me permet de profiter du fait que j'ai eu à créer la chaîne déjà la plupart du temps, et éviter de faire encore une autre copie d'elle. Ce n'est pas exactement de haute performance code mais c'est un bon exemple des possibilités de gens obtenir le blocage de cette fonction. Ce code exige en fait que la variable soit de manière temporaire à l'appel, ou std::move invoquée:

//move from temporary
TextureHandle htex = CreateTexture(128, 128, A8R8G8B8, string("Checkerboard"));

ou

//explicit move (not going to use the variable 'str' after the create call)
string str("Checkerboard");
TextureHandle htex = CreateTexture(128, 128, A8R8G8B8, std::move(str));

ou

//explicitly make a copy and pass the temporary of the copy down
//since we need to use str again for some reason
string str("Checkerboard");
TextureHandle htex = CreateTexture(128, 128, A8R8G8B8, string(str));

mais cela ne compile pas!

string str("Checkerboard");
TextureHandle htex = CreateTexture(128, 128, A8R8G8B8, str);

Aucun de ceux qui vont le faire supplémentaire de la copie. Même si RVO n'est pas utilisé, la nouvelle norme dit que déplacer la construction est préféré à la copie lorsque vous faites des retours je crois.

Je crois que votre deuxième exemple provoque un comportement indéfini, mais parce que vous êtes de retour d'une référence à une variable locale.