Je pense que nous sommes d'accord que l'idiome copy&swap n'a un intérêt profond que quand la classe gère des ressources qui peuvent entraîner l'échec de l'assignation mais permettent un swap garanti sans échec. Dans ce cas, copy&swap donne un moyen systématique d'avoir une assignation transactionnelle: ou elle n'a rien change, ou elle a réussit.
Si il n'y a qu'une ressource, il est souvent possible de la gérer correctement sans passer par l'idiome du copy&swap avec un code assez simple -- même si arriver au code et se convaincre de sa correction ne l'est pas toujours autant, surtout la première fois. Avec plus d'une ressource, ce l'est moins. Faire un constructeur de copie correct et une fonction swap correcte est beaucoup plus simple.
Ce qui ne veut pas dire que l'utilisation de copy&swap doit être systématique. Faire intervenir l'aspect performance pour les autres membres ne gérant pas de ressources me semble un peu léger -- les copier une fois inutilement est très largement inférieur au temps nécessaire pour la gestion des ressources, ce gain ne va convaincre que les microoptimiseur compulsifs d'utiliser un code plus complexe et plus fragile.
Faire intervenir les performances pour la gestion des ressources me semble un critere plus pertinent. L'idiome copy&swap par sa nature ne permet pas de réutiliser les ressources déjà allouées et force leur de-allocation et l'allocation de nouvelles. Ça c'est suffisamment coûteux pour justifier un code plus complexe pour l'éviter. Sans parler du fait que dans le cas de ressources rares, le besoin plus grand en ressources de copy&swap peut entraîner l'échec de l'assignation alors que la réutilisation des ressources déjà allouée aurait permis le succès.
Partager