std :: facultatif: différence effective entre la valeur simple et la valeur qualifiée ref ()

Il n'y a aucune différence entre std :: move (optA) .value () et std :: move (optA.value ()) . value () renvoie simplement une valeur de glissement faisant référence à la valeur contenue, et soit vous pouvez avoir value () renvoyer une lvalue qui est ensuite convertie en une xvalue par std :: move , ou vous pouvez appeler std :: move d'abord et demander à value () de vous donner immédiatement une valeur x (en réalité, la conversion de lvalue to xvalue se produira quelque part dans la méthode value () elle-même). Les surcharges qualifiées ref ne sont évidemment pas très utiles dans ce cas simple, mais peuvent être utiles lorsque l'option optionnelle a été passée par la référence de transfert O && o , et que vous voulez std :: forward (o) .value () pour "faire ce qu'il faut".

f(std::move(optA.value())); // OPTION 2

Y a-t-il une situation possible où value () && fait une différence par rapport à std :: move et value ()?

Tenez compte de ce qui suit:

struct C {string s;};
C func2() {...}

void h(string s);

h(func2().s);

f Le paramètre opt sera initialisé par move. Eh bien techniquement, il sera initialisé directement par la prvalue, mais pré-C ++ 17 signifie qu'il est initialisé par déplacement. Cette initialisation peut être éludée, mais si ce n'est pas le cas, elle se fait via move. Toujours.

Mais qu'en est-il du paramètre de g ? Que devrait-il arriver? Eh bien, considérez ce que cela ferait:

optional<A> func() {...}

void f(optional<A> opt) {...}
void g(A a) {...}

f(func());
g(func().value());

Le paramètre de h est initialisé par move . Pourquoi? Parce que si vous accédez à un sous-objet membre d'une prvalue, l'expression résultante est une xvalue, et est donc éligible pour le mouvement sans utiliser explicitement std::move.

Le && constructeur de facultatif garantit que la valeur fonctionne de la même manière. Si vous l'appelez sur une prvalue temporaire, alors il retournera une valeur x, qui peut être déplacée sans un appel explicite std :: move . Donc dans le cas d'origine, le paramètre de g est initialisé par move, exactement comme il l'aurait fait s'il accédait à un sous-objet membre d'une valeur pr.

Je suppose que les deux versions sont identiques, cependant, la réponse de Nicol Bolas semble intéressante.

En supposant qu'elles aboutissent toutes les deux à une rvalue et que le code n'a pas d'importance, nous n'avons aucune raison d'ignorer la lisibilité .

std::move(optA.value())

Cela suggère de déplacer la variable et de compter sur le rédacteur de la classe pour fournir les bonnes surcharges. S'il manque, vous risquez de le rater.

Certains linters reconnaissent également cela comme une variable à ne plus toucher, ce qui vous empêche de l'utiliser après le déplacement.

  std::move(optA).value()

Ceci convertit cependant la valeur de retour en une rvalue. Je considère surtout ce code comme un bogue. Soit la fonction retourne par valeur (ou référence const) et nous avons écrit beaucoup de code. Sinon, la fonction renvoie une lvalue et vous avez potentiellement ruiné l'état interne de la variable.

Avec cela, je recommande de déplacer systématiquement la variable et de déclencher le déplacement d'un appel de fonction comme une odeur de code. (Même pour std :: facultatif, là où cela ne devrait pas avoir d'importance)