Pour cette fois, je pense que ma vision d'ensemble du problème et totalement correct. D'ailleurs le bench que j'ai fait (où l'ensemble des codes ne présentent pas de problème de fuite mémoire il me semble), montre bien qu'il y a bien un comportement d'elision, même avec de l'allocation dynamique.
Je crois avoir respecter cette règle partout.
Jusque là, oui.
Pas de problème jusque là, si ce n'est que tu te places dans un cas où il ne peut y avoir élision, cas où les deux version de l'opérateur d'affectation ont le même comportement, ce n'est donc pas vraiment dans le sujet, AMA.
Oui, cependant on rendre dans la micro-optimisation là, la discussion tournait autour de l'écriture idiomatique de fonction membre spéciales, l'écriture de code spécifique pour profiter de micro-optimisation est loin d'être idiomatique, AMA.
En effet.
Oui, je n'ai jamais dit le contraire, l'élision permet d'éviter la copie dans le cas d'un temporaire, ce qu'on récupère est bien totalement cohérant, et l'on peut le manipuler commeon veut, son caractère de temporaire fait qu'il va être détruit.
Trouves moi des fuites mémoire dans les codes de mon bench, je n'ai pas vérifier avec Valgrind, mais je suis quasi-certain qu'il n'y en a pas (je n'accorde en général aucun crédit à la vérification de fuite via le gestionnaire des tâche windows, cependant dans ce cas, l'expérience est repeté pas loin d'un demi milliard de fois, j'aurais une fuite mémoire d'un int, je crois qu'elle se verrait même au gestionnaire des tâches).
Tout ton raisonnement est correct, mais tu ne te places jamais dans le cas où il peut y avoir élision, ainsi en effet aucune copies ne peut être élider ...
Pour rappel le cas d'élision pour l'opérateur d'affectation est :
Les autres sont identique que ce soit avec la version A ou const A& de l'opérateur d'affectation.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 A a; a = A();
Partager