Pourquoi ne std::move empêcher RVO?

Dans de nombreux cas de retour d'un local à partir d'une fonction, RVO coups de pied dans. Cependant, je pensais que l'utilisation explicite std::move permettrait au moins de faire respecter le déplacement lors de la RVO ne se fait pas, mais que RVO est toujours en vigueur, lorsque cela est possible. Cependant, il semble que ce n'est pas le cas.

#include "iostream"

class HeavyWeight
{
public:
    HeavyWeight()
    {
        std::cout << "ctor" << std::endl;
    }

    HeavyWeight(const HeavyWeight& other)
    {
        std::cout << "copy" << std::endl;
    }

    HeavyWeight(HeavyWeight&& other)
    {
        std::cout << "move" << std::endl;
    }
};

HeavyWeight MakeHeavy()
{
    HeavyWeight heavy;
    return heavy;
}

int main()
{
    auto heavy = MakeHeavy();
    return 0;
}

J'ai testé ce code avec VC++11 et GCC 4.71, debug et release (-O2) config. La copie ctor n'est jamais appelée. Le mouvement ctor est appelé par VC++11 dans le debug config. En fait, tout semble aller pour le mieux avec ces compilateurs en particulier, mais à ma connaissance, RVO est facultatif.

Cependant, si je utiliser explicitement move:

HeavyWeight MakeHeavy()
{
    HeavyWeight heavy;
    return std::move(heavy);
}

le déplacer ctor est toujours appelée. Donc, en essayant de la rendre "sûr", il est pire.

Mes questions sont les suivantes:

- Pourquoi ne std::move empêcher RVO?

- Quand est-il préférable de "l'espoir pour le meilleur", et s'appuient sur RVO, et quand dois-je utiliser explicitement std::move? Ou, en d'autres termes, comment puis-je laisser le compilateur d'optimisation de faire son travail et toujours appliquer déplacer si RVO n'est pas appliquée?

  • Pourquoi toujours parler de "l'espoir pour le meilleur" ces jours-ci? Quel type de compilateur utilisent-ils qui a le C++11, mais ne peut pas RVO correctement?
  • Copie élision (le mécanisme derrière la RVO) est autorisée que dans certaines, des conditions strictes. Écrit std::move empêche que ces conditions soient remplies.
  • Et ces conditions empêché par std::move sont...?
  • std::move empêche NRVO (nommé RVO). RVO en général n'est pas affecté (autant que je sache)
  • Pouvez-vous indiquer une référence décrivant le raisonnement derrière empêcher cela? Ne déplacez élision jamais arriver?
  • Nope, retour std::move(poids Lourd()); appelle encore les déplacer ctor.
  • Déplacer élision ne se produise, mais pas quand explicitement en utilisant std::move. De drôles de trucs.
  • J'ai pensé que j'étais juste d'être approfondie en faisant explicite std::move est, au contraire il me semble que j'ai été le sabotage moi-même! 😉
  • Je n'ai pas dit que le compilateur ne RVO dans le std::move cas. J'ai seulement dit, qu'ils ne peuvent pas faire NRVO, mais (comme je l'ai dit, autant que je sache) peut encore faire RVO. Il est dépendant de l'implémentation.
  • Vous n'êtes pas seul.
  • Le déménagement peut toujours être ramené si le compilateur peut prouver qu'il ne change pas le programme du comportement.
  • Le problème des cas est celui où le changement de comportement est admise, à savoir l'omission de copier/déplacer constructeur appelle. Depuis le cas de test, par définition, doit contenir les effets secondaires, vous êtes limité à des optimisations qui s'appuient sur une copie élision et les règles du jeu.

InformationsquelleAutor cdoubleplusgood | 2013-10-09
  1. 39

    Le cas où copier et déplacer des élision est permis est trouvé dans la section 12.8 §31 de la Norme (version N3690):

    Lorsque certains critères sont respectés, une mise en œuvre est permis d'omettre de le copier/déplacer la construction d'un objet de classe, même si le constructeur sélectionné pour la copie/déplacement de l'opération et/ou le destructeur de l'objet ont des effets secondaires. Dans de tels cas, la mise en œuvre traite de la source et de la cible de l'omis de copier/déplacer des fonctionnement que simplement deux façons différentes de référence au même objet, et la destruction de cet objet se produit au plus tard à la fois lorsque les deux objets ont été détruits sans l'optimisation. Cette élision de copier/déplacer des opérations, appelées copie élision, est autorisé dans les circonstances suivantes (qui peuvent être combinés pour éliminer plusieurs exemplaires):

    • dans un return déclaration dans une fonction avec une classe de type de retour, lorsque l'expression est le nom d'un non-volatile automatique d'objets (autre qu'une fonction ou catch-clause de paramètre) avec le même cv-non qualifiés de type que le type de retour de fonction, le copier/déplacer opération peut être omis, par la construction de l'automatique des objets directement dans la valeur renvoyée de la fonction
    • [...]
    • lorsque temporaire de la classe de l'objet qui n'a pas été lié à une référence (12.2) sera copié/déplacé vers un objet de classe avec le même cv-non qualifiés de type, le copier/déplacer opération peut être omis, par la construction de l'objet temporaire directement dans la cible de l'omis de copier/déplacer des
    • [...]

    (Les deux cas, j'ai laissé en dehors du cas de le lancer et attraper des objets d'exception, que je considère comme moins important pour l'optimisation.)

    Donc dans une instruction de retour de la copie élision ne peut se faire que si l'expression est le nom d'une variable locale. Si vous écrivez std::move(var), alors il n'est pas le nom d'une variable de plus. Donc le compilateur ne peut pas éluder le déplacement, si elle doit être conforme à la norme.

    Stephan T. Lavavej parlé à Natifs 2013 et expliqué exactement votre situation et pourquoi faut-il éviter std::move() ici. Commencer à regarder à la minute 38:04. En gros, lors du retour d'une variable locale de type de retour alors qu'il est généralement traitée comme une rvalue permettant de déplacer par défaut.

    • C'est la réponse que j'espérais. Je ne suis pas heureux de la situation, mais je comprends mieux.
    • Nous devrions probablement corriger est ainsi que return std::move peuvent être gommés. Si nous pourrions dire que le C++ qui est la référence la valeur de retour d'une fonction est garanti d'être le même que celui d'un particulier de référence de la valeur d'entrée de la fonction, à quelques résultats intéressants pourraient s'ouvrir. (Élision de non-trivial expressions, la durée de vie de l'extension temporaire d'un argument d'entrée à une fonction sans retour temporaire, pour les deux: le deuxième de ce qui est à mon humble avis plus important).
    • Oui, je ne comprends pas la raison d'être de ne pas être capable d'éluder cette. Il est juste plus difficile à faire, permettant aux rédacteurs de compilateur de plus de temps?
    InformationsquelleAutor Ralph Tandetzky
  2. 17

    comment puis-je laisser le compilateur d'optimisation de faire son travail et toujours appliquer déplacer si RVO n'est pas appliquée?

    Comme ceci:

    HeavyWeight MakeHeavy()
{
    HeavyWeight heavy;
    return heavy;
}

    Transformant le retour à un déplacement est obligatoire.

    • Donc, pour en revenir un local est la garantie d'une déplacer dans le pire des cas, et RVO s'applique dans le meilleur des cas?
    • Je suppose que j'ai besoin de faire quelques grep'ping pour return std::move 😉
    • Qui serait effectivement un avertissement utile.
    • Presque. Retour d'un local non-paramètre directement est garanti pour move dans le pire des cas. Quelque chose d'aussi anodin que return condition?heavy1:heavy2; peut empêcher l'implicite move, tandis que if (condition) return heavy1; return heavy2; ne le serait pas. Il est un peu fragile.
    InformationsquelleAutor R. Martinho Fernandes