Est passé par valeur raisonnable par défaut en C++11?

Traditionnelle C++, en passant par valeur dans les fonctions et les méthodes est lent pour des objets de grande taille, et est généralement mal vu. Au lieu de cela, les programmeurs en C++ ont tendance à passer des références, ce qui est plus rapide, mais qui présente toutes sortes de questions complexes autour de la propriété et plus particulièrement autour de la gestion de la mémoire (dans le cas où l'objet est alloué par tas)

Maintenant, en C++11, nous avons des références Rvalue et des constructeurs de déplacement, ce qui signifie qu'il est possible de mettre en œuvre un objet de grande taille (comme un std::vector) ce n'est pas cher pour passer par valeur dans et hors d'une fonction.

Donc, est-ce à dire que la valeur par défaut doit être de passer par valeur pour les instances de types tels que std::vector et std::string? Ce sujet pour les objets personnalisés? Quelle est la meilleure pratique?

  • pass by reference ... which introduces all sorts of complicated questions around ownership and especially around memory management (in the event that the object is heap-allocated). Je ne comprends pas comment c'est compliqué ou difficile pour la propriété? Peut-être que j'ai manqué quelque chose ?
  • Un exemple tiré de l'expérience personnelle. Un thread a un objet de type string. Il est transmis à une fonction qui génère un autre thread, mais inconnu à l'appelant la fonction a pris la chaîne comme const std::string& et non une copie. Le premier thread puis quitté...
  • Qui sonne comme une fonction clairement jamais conçu pour être appelée comme une fonction de thread.
  • D'accord avec iammilind, je ne vois pas de problème. En passant par la const de référence par défaut pour les "gros" objets, et par la valeur pour les plus petits objets. Je l'avais mis de la limite entre les grands et les petits à autour de 16 octets (ou 4 pointeurs sur un système 32 bits).
  • Herb Sutter est Retour à l'essentiel! Essentials of Modern C++ présentation à CppCon suis allé dans pas mal de détail sur cette. Vidéo.
  • Connexes: Comment passer des objets à des fonctions en C++?

InformationsquelleAutor Derek Thurn | 2011-09-29
  1. 135

    C'est raisonnable par défaut si vous avez besoin de faire une copie à l'intérieur du corps. C'est ce que Dave Abrahams préconise:

    Directive: Ne copiez pas vos arguments de la fonction. Au lieu de cela, passer par valeur et laisser le compilateur faire la copie.

    Dans le code, cela signifie ne pas faire ceci:

    void foo(T const& t)
{
    auto copy = t;
    //...
}

    mais ce faire:

    void foo(T t)
{
    //...
}

    qui a l'avantage que l'appelant foo comme suit:

    T lval;
foo(lval); //copy from lvalue
foo(T {}); //(potential) move from prvalue
foo(std::move(lval)); //(potential) move from xvalue

    et seulement un minimum de travail est fait. Vous auriez besoin de deux surcharges de faire de même avec les références, void foo(T const&); et void foo(T&&);.

    Avec cela à l'esprit, maintenant j'écrit mes chers constructeurs en tant que tel:

    class T {
    U u;
    V v;
public:
    T(U u, V v)
        : u(std::move(u))
        , v(std::move(v))
    {}
};

    Sinon, le passage par référence à const est encore raisonnable.

    • +1, surtout pour le dernier bit 🙂 il ne faut pas oublier que les Constructeurs de Déplacement ne peut être invoquée que si l'objet à déplacer n'est pas prévu pour être inchangé par la suite: SomeProperty p; for (auto x: vec) { x.foo(p); } ne convient pas, par exemple. En outre, Déplacer les Constructeurs ont un coût (la plus grande de l'objet, plus le coût), tandis que const& sont essentiellement libres.
    • Mais il est important de savoir ce qu'est "la plus grande de l'objet, plus le coût" de la déplacer signifie en réalité: "plus" signifie en fait "la plus membre de variables qu'il a". Par exemple, le déplacement d'un std::vector avec un million d'éléments les coûts de la même en tant que de déplacer l'un des cinq éléments puisque seul le pointeur vers le tableau sur le tas est déplacé, et non tous les objets dans le vecteur. Il n'est donc pas réellement que les grandes d'un problème.
    • +1 j'ai aussi tendance à utiliser le passage par valeur, puis déplacer construire depuis que j'ai commencé à l'aide de C++11. Cela me fait me sentir un peu mal à l'aise, mais, depuis mon code maintenant a std::move tous sur la place..
    • +1, Donc rien n'a changé depuis '93 en ce qui concerne ce cas précis.
    • Il y a un risque avec const&, qui a déclenché moi un peu de temps. void foo(const T&); int main() { S s; foo(s); }. Cela permet de compiler, même si les types sont différents, si il y a un tee constructeur qui prend un S comme argument. Cela peut être long, car un grand T objet peut être se construit. Vous pouvez pense votre de passer une référence sans la copier, mais peut vous êtes. Voir cette réponse à une question que j'avais posée pour plus d'. Fondamentalement, & habituellement ne se lie qu'à lvalues, mais il y a une exception pour rvalue. Il existe des alternatives.
    • ... Je dois avoir des liens vers le cette réponse au lieu de cela/aswell. Aussi, je je devrais avoir terminé en disant: "il y a une exception pour const&, lui permettant de se lier à des rvalues (par exemple, les copies temporaires)'
    • C'est de vieilles nouvelles, dans le sens que c'est quelque chose que vous avez toujours eu à être conscients et même avant C++11. Et rien n'a vraiment changé par rapport à cela.
    • Je ne comprends pas cette phrase : "Vous auriez besoin de deux surcharges de faire de même avec les références, void foo(T const&); et void foo(T&&);" parce que foo(T const&) peut gérer la lvalue,xvalue,prvalue, alors pourquoi ne vous dire que nous avons d'utiliser deux surcharges pour obtenir le même résultat ?
    • le même " suppose que l'un des objectifs est encore, pour éviter les recopies inutiles, en particulier en favorisant les (potentiels) se déplace sur (inconditionnel) copies.

    InformationsquelleAutor Luc Danton
  2. 71

    Dans presque tous les cas, votre sémantique doit être soit:

    bar(foo f); //want to obtain a copy of f
bar(const foo& f); //want to read f
bar(foo& f); //want to modify f

    Toutes les autres signatures doivent être utilisés qu'avec parcimonie, et avec une bonne justification. Le compilateur va maintenant presque toujours travailler dans la manière la plus efficace. Vous pouvez tout simplement écrire votre code!

    • Bien que je préfère en passant un pointeur si je vais modifier un argument. Je suis d'accord avec le Google guide de style que de ce fait, il est plus évident que l'argument va être modifié sans avoir à double-vérifier la fonction de la signature ( google-styleguide.googlecode.com/svn/trunk/... ).
    • La raison que je n'aime pas le passage de pointeurs, c'est qu'il ajoute une possible défaillance de l'état de mes fonctions. J'essaie d'écrire tous mes fonctions, de sorte qu'ils sont sensiblement corriger, car il réduit considérablement l'espace pour les bugs se cacher dans. foo(bar& x) { x.a = 3; } est un diable de beaucoup plus fiable (et lisible!) que foo(bar* x) {if (!x) throw std::invalid_argument("x"); x->a = 3;
    • Lybbert: Avec un pointeur de paramètre, vous n'avez pas besoin de vérifier la fonction de la signature, mais vous devez vérifier que la documentation pour savoir si vous êtes autorisé à passer des pointeurs null, si la fonction ownsership, etc. À mon humble avis, un pointeur de paramètre transmet beaucoup moins d'informations qu'un non-const de référence. Je conviens cependant qu'il serait agréable d'avoir une indication visuelle sur le site d'appel que l'argument peut être modifiée (comme le ref mot-clé en C#).
    • Ceux qui sont à la fois des points valides.
    • En ce qui concerne le passage par valeur et en s'appuyant sur la sémantique de déplacement, je crois que ces trois choix de faire un meilleur travail en expliquant l'utilisation prévue du paramètre. Ce sont les lignes directrices j'ai toujours suivre.
    • Concernant l'utilisation de pointeurs, vous pouvez écrire une simple puce de type pointeur qui va effectuer cette vérification pour vous, @Ayjay. Nous pourrions l'appeler out<> pour les 'param'. Ensuite, la signature de la fonction serait bar(out<foo> f) au lieu de bar(foo * f).
    • N'est-ce pas pire? La plaine vieux non-const de référence est beaucoup plus facile à traiter par rapport au pointeur de la...
    • que pourrait-il exiger que le site d'appel prendre leurs responsabilités pour faire en sorte qu'il n'est pas déréférencer un pointeur null lors du passage à une fonction qui prend l'argument par référence. À un certain stade, certaines de vos pointeurs doivent être vérifiés pour les nuls, et je suggère que vous pourriez construire que de vérifier, dans un pointeur intelligent. Mais ouais, ayant pour type -> au lieu de . est ennuyeux 🙂 (en Fait, c'est shared_ptr destiné à ne jamais être nulle? Bien que (je pense) unique_ptr est?)
    • shared_ptr destiné à ne jamais être nulle? Bien que (je pense) unique_ptr est? ces Deux hypothèses sont fausses. unique_ptr et shared_ptr peut contenir null/nullptr valeurs. Si vous ne voulez pas vous soucier de valeurs null, vous devriez être en utilisant des références, parce qu'ils ne peuvent jamais être null. En outre, vous ne pas avoir à taper ->, que vous trouverez à être ennuyeux 🙂
    • Ainsi, les références peuvent être null ainsi 🙂 void f(A& r) {} A* p = nullptr; /* result of some find, for example */ f(*p);
    • En désaccord avec le passage par valeur d'en prendre une copie. Voir la réponse ci-dessous.

    InformationsquelleAutor Ayjay
  3. 10

    Passer des paramètres par valeur si à l'intérieur du corps de la fonction vous avez besoin d'une copie de l'objet ou seulement besoin de déplacer l'objet. Passer par const& si vous avez uniquement besoin de la non-mutation de l'accès à l'objet.

    Copie d'objet exemple:

    void copy_antipattern(T const& t) { //(Don't do this.)
    auto copy = t;
    t.some_mutating_function();
}

void copy_pattern(T t) { //(Do this instead.)
    t.some_mutating_function();
}

    Déplacement d'objet exemple:

    std::vector<T> v; 

void move_antipattern(T const& t) {
    v.push_back(t); 
}

void move_pattern(T t) {
    v.push_back(std::move(t)); 
}

    Non-mutation d'accès exemple:

    void read_pattern(T const& t) {
    t.some_const_function();
}

    Pour la justification, voir ces billets de blog par Dave Abrahams et Xiang Fan.

    InformationsquelleAutor Edward Brey