Parce que ça optimise quelque chose en termes de performances de passer à la version pre-increment ?
Oui, en c++.
Quand tu déclares en pré-incrément, tu n'a pas de copie.
// .hClasse&operator++();//.cppClasse&operator++(){// Code d'incrément (plus ou moins long)return*this;}
Ici, on retourne une référence sur l'objet incrémenté.
// .hClasseoperator++(int);// le paramètre signifie post incrément// .cppClasseoperator++(int){Classetmp=*this;// Copie de l'objet// Code d'incrément// On retourne une copie de l'objet avant l'incrément. Ce ne peut-être une réf, car il est sur la pile.returntmp;// Copie de l'objet}
Ici, on a deux copies, ce qui peut poser un problème si l'objet est gros. C'est pour ça, notamment sur les fonctions template où tu ne présuppose pas ce que tu as comme objet qu'il vaut mieux faire des pré-incrément en c++.
Je ne sais pas si c++11 permet avec le && d'écrire les post-incrément mieux ?
[^] # Re: Un code d'un langage que l'on ne connaît pas ne peut pas servir pour un bench!
Posté par Anthony Jaguenaud . En réponse au journal Quand Pythran fait tourner du Python plus vite que du C++, c'est que.... Évalué à 2. Dernière modification le 27 juin 2014 à 14:46.
Oui, en c++.
Quand tu déclares en pré-incrément, tu n'a pas de copie.
Ici, on retourne une référence sur l'objet incrémenté.
Ici, on a deux copies, ce qui peut poser un problème si l'objet est gros. C'est pour ça, notamment sur les fonctions template où tu ne présuppose pas ce que tu as comme objet qu'il vaut mieux faire des pré-incrément en c++.
Je ne sais pas si c++11 permet avec le
&&d'écrire les post-incrément mieux ?