Le pass-by-value est-il une valeur par défaut raisonnable dans C ++ 11?

Dans le C ++ traditionnel, le passage par valeur dans les fonctions et les méthodes est lent pour les objets volumineux et est généralement mal vu. Au lieu de cela, les programmeurs C ++ ont tendance à passer des références, ce qui est plus rapide, mais qui introduit toutes sortes de questions compliquées autour de la propriété et en particulier de la gestion de la mémoire (dans le cas où l'objet est alloué en 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 d'implémenter un objet volumineux (comme un std::vector) qui est bon marché à passer par valeur dans et hors d'une fonction.

Alors, cela signifie-t-il que la valeur par défaut devrait être de passer par valeur pour les instances de types tels que std::vectoret std::string? Qu'en est-il des objets personnalisés? Quelle est la nouvelle meilleure pratique?

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

Recommandation: ne copiez pas vos arguments de fonction. Au lieu de cela, transmettez-les par valeur et laissez le compilateur faire la copie.

Dans le code, cela signifie ne pas faire ceci:

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

mais faites ceci:

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

qui a l'avantage que l'appelant peut utiliser foocomme ceci:

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

et seul un travail minimal est effectué. Vous auriez besoin de deux surcharges pour faire la même chose avec les références, void foo(T const&);et void foo(T&&);.

Dans cet esprit, j'ai maintenant écrit mes précieux constructeurs en tant que tels:

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

Sinon, passer par référence à conststill est raisonnable.

Dans presque tous les cas, votre sémantique devrait ê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 ne doivent être utilisées qu'avec parcimonie et avec une bonne justification. Le compilateur les travaillera désormais à peu près toujours de la manière la plus efficace. Vous pouvez simplement continuer à écrire votre code!

Passez les paramètres par valeur si, à l'intérieur du corps de la fonction, vous avez besoin d'une copie de l'objet ou que vous avez seulement besoin de déplacer l'objet. Passez const&si vous n'avez besoin que d'un accès non mutant à l'objet.

Exemple de copie d'objet:

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

Exemple de déplacement d'objet:

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

Exemple d'accès sans mutation:

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

Pour en savoir plus, consultez ces articles de blog de Dave Abrahams et Xiang Fan .

La signature d'une fonction doit refléter son utilisation prévue. La lisibilité est importante, également pour l'optimiseur.

C'est la meilleure condition préalable pour qu'un optimiseur crée le code le plus rapide - en théorie du moins et sinon en réalité, dans quelques années la réalité.

Les considérations de performances sont très souvent surestimées dans le contexte du passage de paramètres. La transmission parfaite en est un exemple. Les fonctions comme emplace_backsont pour la plupart très courtes et intégrées de toute façon.