C ++ 11 rvalues ​​and move semantics confusion (instruction de retour)

J'essaie de comprendre les références rvalue et de déplacer la sémantique de C ++ 11.

Quelle est la différence entre ces exemples et lequel d'entre eux ne fera pas de copie vectorielle?

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

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

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

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 un temporaire qui est capturé rval_ref. Ce temporaire aura sa durée de vie prolongée au-delà de la rval_refdéfinition et vous pouvez l'utiliser comme si vous l'aviez pris par valeur. Ceci est très similaire à ce qui suit:

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

sauf que dans ma réécriture, vous ne pouvez évidemment pas utiliser rval_refde manière non constante.

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_refcontient désormais une référence à la destruction tmpà l'intérieur de la fonction. Avec un peu de chance, ce code planterait immédiatement.

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 au premier. Le std::movesur tmpest inutile et peut effectivement être un pessimization de performance car il inhibe l' optimisation de la valeur de retour.

La meilleure façon de coder ce que vous faites est:

Meilleur entrainement

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

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

C'est à dire comme vous le feriez en C ++ 03. tmpest implicitement traité comme une valeur r dans l'instruction return. Il sera soit retourné via l'optimisation de la valeur de retour (pas de copie, pas de déplacement), ou si le compilateur décide qu'il ne peut pas exécuter RVO, alors il utilisera le constructeur de déplacement de vector pour effectuer le retour . Ce n'est que si RVO n'est pas effectué et si le type retourné n'a pas de constructeur de déplacement que le constructeur de copie sera utilisé pour le retour.

Aucun d'eux ne copiera, mais le second fera référence à un vecteur détruit. Les références rvalue nommées n'existent presque jamais dans le code normal. Vous l'écrivez comme vous auriez écrit une copie en C ++ 03.

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

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

Sauf que maintenant, le vecteur est déplacé. L' utilisateur d'une classe ne gère pas ses références de valeur dans la grande majorité des cas.

La réponse simple est que vous devez écrire du code pour les références rvalue comme vous le feriez pour le code des références régulières, et vous devez les traiter de la même manière mentalement 99% du temps. Cela inclut toutes les anciennes règles concernant le renvoi de références (c.-à-d. Ne renvoyez jamais une référence à une variable locale).

À moins que vous n'écriviez une classe de conteneur de modèle qui doit tirer parti de std :: forward et être capable d'écrire une fonction générique qui accepte des références lvalue ou rvalue, cela est plus ou moins vrai.

L'un des grands avantages du constructeur de déplacement et de l'affectation de déplacement est que si vous les définissez, le compilateur peut les utiliser dans les cas où le RVO (optimisation de la valeur de retour) et NRVO (l'optimisation de la valeur de retour nommée) n'ont pas été invoqués. C'est assez énorme pour renvoyer efficacement des objets coûteux comme des conteneurs et des chaînes de valeur à partir de méthodes.

Maintenant, là où les choses deviennent intéressantes avec les références rvalue, c'est que vous pouvez également les utiliser comme arguments pour les fonctions normales. Cela vous permet d'écrire des conteneurs qui ont des surcharges pour la référence const (const foo & other) et la référence rvalue (foo && other). Même si l'argument est trop compliqué à passer avec un simple appel de constructeur, il peut toujours ê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é mis à jour pour avoir des surcharges de mouvement pour presque tout (clé et valeurs de hachage, insertion de vecteur, etc.), et c'est là que vous les verrez le plus.

Vous pouvez également les utiliser pour des fonctions normales et si vous ne fournissez qu'un argument de référence rvalue, vous pouvez forcer l'appelant à créer l'objet et laisser la fonction effectuer le déplacement. C'est plus un exemple qu'une très bonne utilisation, mais dans ma bibliothèque de rendu, j'ai assigné une chaîne à toutes les ressources chargées, afin qu'il soit plus facile de voir ce que chaque objet représente dans le débogueur. L'interface ressemble à 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 d '«abstraction qui fuit» mais me permet de profiter du fait que je devais déjà créer la chaîne la plupart du temps, et éviter d'en faire une autre copie. Ce n'est pas exactement du code haute performance, mais c'est un bon exemple des possibilités que les gens maîtrisent cette fonctionnalité. Ce code nécessite en fait que la variable soit temporaire à l'appel, ou std :: move invoqué:

// 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 compilera pas!

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

Pas une réponse en soi , mais une ligne directrice. La plupart du temps, il est inutile de déclarer une T&&variable locale (comme vous l'avez fait avec std::vector<int>&& rval_ref). Vous devrez toujours std::move()les utiliser dans foo(T&&)les méthodes de type. Il y a aussi le problème qui a déjà été mentionné que lorsque vous essayez de renvoyer une telle rval_reffonction, vous obtiendrez la référence standard à fiasco temporaire détruit.

La plupart du temps, j'irais avec le modèle suivant:

// Declarations
A a(B&&, C&&);
B b();
C c();

auto ret = a(b(), c());

Vous ne détenez aucune référence aux objets temporaires retournés, vous évitez ainsi l'erreur de programmeur (inexpérimenté) qui souhaite utiliser un objet déplacé.

auto bRet = b();
auto cRet = c();
auto aRet = a(std::move(b), std::move(c));

// Either these just fail (assert/exception), or you won't get 
// your expected results due to their clean state.
bRet.foo();
cRet.bar();

Évidemment, il existe des cas (bien que plutôt rares) où une fonction renvoie vraiment un T&&qui est une référence à un objet non temporaire que vous pouvez déplacer dans votre objet.

Concernant RVO: ces mécanismes fonctionnent généralement et le compilateur peut très bien éviter la copie, mais dans les cas où le chemin de retour n'est pas évident (exceptions, ifconditions déterminant l'objet nommé que vous retournerez, et probablement quelques autres) les références sont vos sauveurs (même si potentiellement plus coûteux).

Aucun de ceux-ci ne fera de copie supplémentaire. Même si RVO n'est pas utilisé, la nouvelle norme dit que la construction de mouvement est préférable de copier lors des retours, je crois.

Je crois que votre deuxième exemple provoque un comportement indéfini, car vous renvoyez une référence à une variable locale.

Comme déjà mentionné dans les commentaires de la première réponse, la return std::move(...);construction peut faire la différence dans des cas autres que le retour de variables locales. Voici un exemple exécutable qui documente ce qui se passe lorsque vous retournez un objet membre avec et sans std::move():

#include <iostream>
#include <utility>

struct A {
  A() = default;
  A(const A&) { std::cout << "A copied\n"; }
  A(A&&) { std::cout << "A moved\n"; }
};

class B {
  A a;
 public:
  operator A() const & { std::cout << "B C-value: "; return a; }
  operator A() & { std::cout << "B L-value: "; return a; }
  operator A() && { std::cout << "B R-value: "; return a; }
};

class C {
  A a;
 public:
  operator A() const & { std::cout << "C C-value: "; return std::move(a); }
  operator A() & { std::cout << "C L-value: "; return std::move(a); }
  operator A() && { std::cout << "C R-value: "; return std::move(a); }
};

int main() {
  // Non-constant L-values
  B b;
  C c;
  A{b};    // B L-value: A copied
  A{c};    // C L-value: A moved

  // R-values
  A{B{}};  // B R-value: A copied
  A{C{}};  // C R-value: A moved

  // Constant L-values
  const B bc;
  const C cc;
  A{bc};   // B C-value: A copied
  A{cc};   // C C-value: A copied

  return 0;
}

Vraisemblablement, cela return std::move(some_member);n'a de sens que si vous voulez réellement déplacer le membre de classe particulier, par exemple dans un cas où class Creprésente des objets adaptateurs de courte durée dans le seul but de créer des instances de struct A.

Remarquez comment struct Ase fait toujours copié sur class B, même lorsque l' class Bobjet est une valeur de R. C'est parce que le compilateur n'a aucun moyen de dire que class Bl'instance de struct Ane sera plus utilisée. Dans class C, le compilateur possède ces informations std::move(), c'est pourquoi il struct Aest déplacé , sauf si l'instance de class Cest constante.