Discussion :

[epsilon68]

bonjour,

il y a un certain temps, quelqu'un de Trolltech (Nokia) avait fait un benchmark pour mesurer l'impact du COW et demontrer que c'etait une bonne solution.

voici le lien:
http://labs.trolltech.com/blogs/2006...it-worth-it-2/

Que pensez-vous du benchmark et avez-vous changé d'avis?

ps: ci-joint les sources pour Qt 4.4.1

[yan]

avez-vous changé d'avis?

Comment cela?

[Alp]

Je pense que ça peut valoir le coup, cf les 3 GOTW qu'il donne en lien. Ca dépend de ce que tu implémentes avec COW aussi...

[screetch]

ca depend aussi si ca resiste bien au multi thread a haut nombre de threads

[epsilon68]

Comment cela?

beaucoup de personnes critiquent Qt pour le COW donc j'aimerais savoir s'ils ont changé d'avis...

[loufoque]

Le COW ça ne sert qu'à améliorer la performance dans le cas où l'application fait des copies alors qu'elle n'en a pas besoin.
Donc si l'application est bien conçue, elle qu'elle ne fait que des copies quand elle en a besoin, alors ça ne sert à rien, au contraire ça rajoute un coût en performance.

Après ça peut quand même être utile pour faire du partage implicite de parties de structures de données à base de nœuds, mais c'est un cas qui se traite vraiment à part.

[epsilon68]

ca permet aussi d'avoir une syntaxe plus legere dans le code...

Code :

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

auto_ptr<MonSuperLourdObjet> creerMonObjet()

vs

Code :

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

MonSuperLourdObject creerMonObjet()

non ? qu'en pensez-vous ?

[yan]

beaucoup de personnes critiquent Qt pour le COW donc j'aimerais savoir s'ils ont changé d'avis...

Si tu aurais un lien sur cela, ça m'intéresse.
Pour moi je trouve que c'est un très bon compromis et que cela simplifie beaucoup de question.

Par exemple :

Code :

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

1
2
3
4
5
6
 
QStringList list;
list<<"aa"<<"bb";
QStringListModel modelList(list);
 
QStringList list2 =modelList.stringList () ;

La même memoire sera utilisé tant que cette mémoire ne doit pas être modifié.

Cela à encore plus d'utilité avec l'utilisation de slot entre thread. Si cela peut eviter une copi inutile, et cela sans que personne s'en aperçoive!!!

Pour moi c'est un comme une référence intelligente
[edit]
mais qui as un coup.

[epsilon68]

Si tu aurais un lien sur cela, ça m'intéresse.

oui ... principalement celle-la :
http://www.developpez.net/forums/d196604/c-cpp/bibliotheques/boost-vs-qt/


puis partant du COW, je m'etais demandé pour les collections de Qt s'il ne fallait pas les utiliser car je ne trouve (trouvais) pas efficace de renvoyer une collection STL ni elegant de la passer en parametre:
http://www.developpez.net/forums/d34...-tulip-vs-stl/

et toi ? preferes-tu la STL ou Qt Tulip?

[loufoque]

Je vois pas le rapport entre le COW et le retour par valeur...

Le retour par valeur fait au pire un déplacement en C++0x (une copie en C++03), et fait dans les bons cas rien du tout grâce à la NRVO.

Retourner par valeur, c'est bien.

[epsilon68]

je ne suis pas d'accord. (voir le 2ieme lien)
avec gcc, la collection n'est pas copiee que si on fait une affectation par initialisation:

Code :

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

vector<string> stringlist = createMyStringList();

mais pas

Code :

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

1
2
vector<string> stringlist;
stringlist = createMyStringList();

alors retourner par copie, non si on se tape les recopies, et attention au compilateur qui n'optimiserait pas ...

[Alp]

D'où l'intérêt du COW.

Mais (en supposant que j'ai bien compris) en C++0x l'intérêt du COW sera quasi nul (réécrire Qt en C++0x ? ).

[yan]

Mais (en supposant que j'ai bien compris) en C++0x l'intérêt du COW sera quasi nul (réécrire Qt en C++0x ? ).

pourquoi??

[HanLee]

pourquoi??

Grâce à la "move semantic".

[Alp]

Grâce à la "move semantic".

Tout à fait, grâce à la sémantiquement de mouvement et rvalue references.

[epsilon68]

Tout à fait, grâce à la sémantiquement de mouvement et rvalue references.

ca donnerait donc si je ne m'abuse:

Code :

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

MonSuperLourdObject&& creerMonObjet()

j'ai l'impression que ca va être super facile à utiliser et super agreable à lire le code

[yan]

Tout à fait, grâce à la sémantiquement de mouvement et rvalue references.

mais l'intêret du cow c'est bien plus que cela, sinon ca sert à rien!!!!!

Code :

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

1
2
3
 QPixmap p1, p2;
 p1.load("image.bmp");
 p2 = p1;                        // p1 and p2 share data

ben tant que p1 et p2 ne sont pas modifié, ils ont la même memoire partagé

Code :

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

1
2
3
4
QPainter paint;
 paint.begin(&p2);               // cuts p2 loose from p1
 paint.drawText(0,50, "Hi");
 paint.end();

On modifie p2, la memoire ne peut plus être partager. donc une copie de la memoire est faite pour p2 et on modifie p2.

C'est ca qui rend interessant le cow : ne pas dupliquer de la memoire pour rien, et juste dupliquer quand il faut!!!

Le COW ça ne sert qu'à améliorer la performance dans le cas où l'application fait des copies alors qu'elle n'en a pas besoin.
Donc si l'application est bien conçue, elle qu'elle ne fait que des copies quand elle en a besoin, alors ça ne sert à rien, au contraire ça rajoute un coût en performance.

C'est vrai et faux. je ne pense pas que l'on puisse toujours savoir quand un objet doit être copié. C'est un compromis. Tous le monde n'étant pas de super spécialiste, Qt permet des faire du code ayant de trés bonne perf, sans que les gens se casse la tête sur le fait de copier ou non un objet

Après ça peut quand même être utile pour faire du partage implicite de parties de structures de données à base de nœuds, mais c'est un cas qui se traite vraiment à part.

j'ai pas compris

[loufoque]

La syntaxe pour retourner un objet c'est pas

MonSuperLourdObject&& creerMonObjet()

mais

Code :

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

MonSuperLourdObject creerMonObjet()

creerMonObjet() est une rvalue, donc ça se déplace.

[epsilon68]

justement je ne pense pas que ce soit fait automatiquement comme tu l'ecris-

[Alp]

C'est justement fait avec std::move (enfin, ce sera fait, c'est dans C++0x uniquement).