Reference et retour de fonction par valeur

Bonjour,

Je suis tombé il y a quelques jours sur un blog qui montrait, dans son exemple sur les références le code suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class Retour { public: void g() const {} };   Retour f() { return Retour(); }   int main(int argc, char *argv[]) { const Retour &retour = f(); retour.g(); return 0; }

---

Le blog expliquait que l'assignation de la variable de retour de la fonction a une référence permettait de s'alléger d'une copie.

Je ne trouve aucune autre références à cette pratique sur le net et n'ai rien lu non plus qui parle de cela dans les bouquins de Sutter/Meyers qui parlent des bonnes pratiques.

Je me demande donc si cette optimisation est vraiment une bonne pratique, selon vous ?

Alors si j'ai tout bien compris du c/c++ ... (ce qu'est pas dit)

Il y a un premier objet de type Retour créé ici

Code:

---

return Retour();

---

Comme la fonction retourne l'objet par valeur, un deuxième objet est créé et copié à partir du premier.

Ensuite si tu fais

Code:

---

const Retour retour = f();

---

alors un troisième objet de type Retour est créé puis copié à partir du deuxième. Alors que si tu fais :

Code:

---

const Retour & retour = f();

---

Il n'y a pas de troisième objet créé ni même copié mais la référence de l'objet retourné par la fonction est stocké dans la référence retour.

Les constructeurs par déplacement à venir (si j'ai tout bien compris encore) pourront réduire le nombre de créations/copies dans les 2 cas de 1.

Flo.

Voilà

Cela évite bien une recopie mais ne risque-t-on pas de faire une référence vers un objet qui vas être dépiler ? En cascadant les fonction du genre:

Code:

---

1 2 3 4 5 6 7 8 9 10

Retour f(){ return Retour(); }   void h(Retour& r){ r = f(); }   int main(){ Retour r; h(r); // Ici, r serait une référence vers une variable local de f, donc qui n'existe plus... }

---

Ce code ne compile pas mais c'est pour montrer l'idée. (En remplaçant les ref par des pointeurs, ça compile et ça montre parfaitement pourquoi les pointeurs sont dangereux :ccool:).

j'ai beau tester avec différents compilateurs et avec du code a effet de bord, le code que tu montres n'effectue pas de copie sur sunCC, gcc et msvc.

Oui c'est tout à fait normal.

Dans le cas normal il devrait y avoir :
- Construction dans le scope de la fonction
- Copie dans un objet temporaire hors du scope de la fonction
- Affectation à une référence constante (le consante est important car c'est un objet temporaire).

Or il y a des règles (nommées copy-elision dans la norme, et souvent distingués en 3 catégorie)

- (N)RVO : (Le N c'est pour Named) Permet au compilateur de construire directement l'objet dans l'objet temporaire hors du scope de la function si celui ci a le même type de base que le type de retour

- Copy-Elision : Permet au compilateur de construire directement dans un objet qui devrait être copié depuis un temporaire quand ceux-ci ont le même type de base.

Marche aussi pour la move-semantic (et cf norme pour les détails, il y a d'autre cas de cette règle plus spécifique).

Dans ton cas c'est la première règle qui s'applique, si tu enlèves la référence constante et tu verras qu'il n'y a aussi qu'une construction, la seconde règle se combine ainsi à la première.

A noter que le compilateur PEUT faire ces optimisation mais qu'il n'est pas obligé de les faire. Cependant ca a une incidence sur notre facon de coder : il ne faut pas que nos constructeur de copie / destructeur (/move-ctor) aient des effets de bord, ie qu'il ne fasse pas autre chose que copier/détruire, sinon l'optimisation du compilateur risque d'avoir des effets inatendues sur notre code.