Je pense que c'est lié au fait qu'un constructeur peut envoyer une exception.
Par contre cela ne va t'il pas être moins performant pour les objet non dynamic? ou le compilo est assez grand pour éviter des copies inutile?
Version imprimable
Je pense que c'est lié au fait qu'un constructeur peut envoyer une exception.
Par contre cela ne va t'il pas être moins performant pour les objet non dynamic? ou le compilo est assez grand pour éviter des copies inutile?
Je ne sais pas trop, mais en effet c'est sûrement lié aux exceptions.
De plus, le jour où tu feras des pointeurs intelligents avec comptage de références, intrusif ou non, tu verras que la copie+swap est plus sûre que l'affectation manuelle.
Ça permet d'avoir une sémantique rollback.
Si une exception est levée lors de d'une affectation, l'idéal c'est que l'objet contienne alors l'ancienne valeur.
Si tu fais simplement membre à membre, il est possible que l'assignation d'un membre lève une exception alors que d'autres membres ont déjà été assignés, tu te retrouves donc avec un objet à demi assigné. Ça peut être sûr ou non en fonction de tes invariants, mais dans tous les cas tu n'as pas de sémantique rollback.
Il y a de nombreux types qui n'ont pas d'assignation rollback, boost::variant depuis quelques temps par exemple il me semble. Si une affectation échoue, ton objet peut se retrouver dans un état synthétique. Personnellement, je trouve ça assez inélégant.
Mais si une assignation rollback n'a pas de coût significatif (dans le cas de variant, elle en a un), autant le faire.
ok merci, c'est très clair