Discussion :

[Matthieu Brucher]

Exact, un code propre, c'est un code qu'on comprend directement en lisant, avec des hacks, c'est plus le cas, et c'est déjà de l'optimisation, alors qu'on ne sait même pas si ce sera critique !

[Pragmateek]

Bon OK je vais me contenter d'un passage par référence ce sera le plus simple.
Sinon est-ce qu'il n'y a pas de mécanisme d'optimisation lors de la copie d'un trés grand tableau:un style de swap géré automatiquement; ou est-ce que dans tous les cas la recopie est effectué "bêtement" si rien n'est indiqué par le programmeur.

[Laurent Gomila]

Le mieux que tu puisses espérer comme optimisation sur un retour par valeur, c'est la RVO (Return Value Optimization), qui évite parfois une recopie lorsque tu construis directement ton objet sur la ligne du return. Mais ça dépend fortement du compilo.

Parfois, les grosses classes copiables implémentent aussi une sémantique de déplacement, ce qui permet lors d'une copie de déplacer les données plutôt que de les copier. C'est le cas par exemple dans certaines classes de matrices, si je me souviens bien.

Tu peux aussi simuler ce comportement avec std::auto_ptr (toujours si je me souviens bien).

[Pragmateek]

ce qui permet lors d'une copie de déplacer les données plutôt que de les copier

déplacer, copier c'est pas la même chose?
Tu veux dire au niveau des pointeurs sur les zones mémoire.

[Laurent Gomila]

Déplacer signifie déplacer la "responsabilité", pas les données en elles-mêmes. En gros tu vas passer ton pointeur vers les données d'une instance à une autre.

[Pragmateek]

OK je marque le sujet .

Merci pour votre aide.

[Matthieu Brucher]

Parfois, les grosses classes copiables implémentent aussi une sémantique de déplacement, ce qui permet lors d'une copie de déplacer les données plutôt que de les copier. C'est le cas par exemple dans certaines classes de matrices, si je me souviens bien.

Tu peux aussi simuler ce comportement avec std::auto_ptr (toujours si je me souviens bien).

Ca ressemble un peu au Copy-On-Write. Ca permet de faire des copies à peu de frais, en comptant le nombre de références à l'espace mémoire qu'on partage. Par exemple, si on fait brutalement, sur des matrices :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
a = b+c;
c = a;

il faudrait recopier à chaque fois le résultat de l'addition dans a, puis a dans c, ce qui est long. Làs, on copie simplement l'espace mémoire et on dit indique qu'il y a 2 objets qui utilisent cet espace.
Maintenant, si on veut modifier a, il faut recopier a dans un nouvel espace, et indiquer qu'on ne partage plus qu'avec c.
Ca marche très bien avec des boost::shared_ptr<>

MAintenant, si on sait qu'on a juste une seule copie valide à chaque fois, effectivement les std::auto_ptr<> sont idéals car ils transmettent la responsabilité au lieu de la partager.

[Luc Hermitte]

Les RVO suivant les compilos marchent plutôt bien. J'ai été supris par SunWSPro CC qui se débrouillait pas mal du tout.
Sinon, les types auto_xxx (il n'y a pas un auto_array chez boost ? -- ou alors, c'est chez adobe?) qui implémentent une sémantique de déplacement sont globalement plus efficaces (et simples à mettre en oeuvre) que le COW -- qui pose des petits problèmes de coût obligatoire en multi-threads.

Avec le COW, tout parait plus simple car il n'y a qu'un seul type à manipuler. Avec la sémantique de déplacement, aujourd'hui (les rvalue reférences pourraient changer la donner en C++0x -- si acceptées), il faut se balader avec deux types. Avec les passages d'arguments en [out] (référence non constante), l'écriture est un chouilla moins naturelle.

[Matthieu Brucher]

Chez Boost, ils n'ont pas d'auto_xx, c'est scoped_xxx - non copiable -, shared_xxx, instrusive_ptr ou weak_xxx
De toute manière, le COW n'est à utiliser que dans des cas très précis.