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 !
Version imprimable
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 !
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.
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).
déplacer, copier c'est pas la même chose?Citation:
ce qui permet lors d'une copie de déplacer les données plutôt que de les copier
Tu veux dire au niveau des pointeurs sur les zones mémoire.
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.
OK je marque le sujet :resolu:.
Merci pour votre aide.:D
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 :Citation:
Envoyé par Laurent Gomila
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.Code:
2
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.
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.
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.