Re: Value Semantics Rocks

J'ai le sentiment que tu as mal compris mes propos, voire que tu les déformes.

• Je ne connais aucun compilateur qui ne fait pas de "return value optimization". Gcc, Clang, Visual Studio, PGI, Intel font tous ces optimisations. Comme signalé dans la news, Gcc le fait même en -O0 et il faut une option speciale pour ne pas le faire. Donc vous pouvez renvoyer des gros objets par valeur. J'ai dit dans mon post qu'il fallait cependant faire attention à une ou deux règles pour cela. Voici un premier cas où on est sur que ces compilateurs optimisent.

U f(const T& input) {
 U output{};
 // n'importe quoi ensuite si tous les "codepath" contiennent un return U
}

Le deuxième cas est celui où le programme peut renvoyer des objets différents mais que ceux si sont tous construits sur le return.

U f(const T& input) {
 ...
 if (...) {
 return U{...};
 } else {
 return U{...};
 }
}

Évidemment, un code du type:

U f(const T& input) {
 U out0{...};
 U out1{...};
 if (...) {
 return out0;
 } else {
 return out1;
 }
}

ne peut pas bénificier de return value optimisation car à la construction des objets, on ne sait pas lequel va être renvoyé.

• Enfin l'exemple où je disais qu'il fallait le compilo Intel ou une version récente de Gcc pour voir une accéleration de performance avec un retour par valeur a été choisi parce qu'il est simple à expliquer. Si vous prenez un compilateur qui n'est pas aussi bon, les deux codes seront simplement aussi rapides sur cet exemple. À noter qu'il y a plein d'autres cas où même une vieille version de gcc produira un code plus performant avec un retour par valeur.

Donc je maintiens mon propos : pour la performance en C++, renvoyez par valeur.