Discussion :

[Luc Hermitte]

C'est comme toute technique. Elle a ses avantages et ses inconvénients.
Et aujourd'hui, j'ai l'impression qu'elle est essentiellement utilisée comme un palliatif à un manque du C++.

Car après, les histoires de grosses valeurs que l'on peut partager et qui d'un coup se transforment en entités qui peuvent muter ... Je ne sais pas. Il y a comme un truc qui me perturbe.

[loufoque]

Aussi -- surtout -- les cas où on ne modifie pas et donc où toutes les occurrences peuvent référencer la même zone mémoire.

Si tu ne modifies pas, pourquoi copier ?
Tu aliases (références), tu transfères (déplaces), ou tu partages (comptage de référence / ramasse-miettes / etc.), suivant ce que tu veux vraiment faire.

[yan]

ou tu partages (comptage de référence / ramasse-miettes / etc.),

Ben c'est e que fait le COW. Sauf que le cow va copier si tu modifie une des occurentes.

[Jean-Marc.Bourguet]

... mais alors c'est bien ou pas bien ?

Ça dépend de ton problème. T'es un manager ou quoi?

Et aujourd'hui, j'ai l'impression qu'elle est
essentiellement utilisée comme un palliatif à un manque du C++.

Car après, les histoires de grosses valeurs que l'on peut partager et qui
d'un coup se transforment en entités qui peuvent muter ... Je ne sais
pas. Il y a comme un truc qui me perturbe.

Je crois que c'est plus un paliatif à un problème de conception que de C++,
on n'arrive pas à choisir entre une sémantique de valeur et d'entité,
peut-être parce qu'on veut trop faire; std::string est un bon exemple.

Note qu'en général le choix est difficile pour les conteneurs. Pour moi
c'est plus des entités (pour preuve, mes conteneurs pré STL en était) mais
si on regarde l'interface de la SL, c'est des valeurs.

Si tu ne modifies pas, pourquoi copier ? Tu
aliases (références), tu transfères (déplaces), ou tu partages (comptage de
référence / ramasse-miettes / etc.), suivant ce que tu veux vraiment
faire.

Le problème des alias, c'est que tu es vulnérable aux modifications. Quand
tu as quelque chose qui est essentiellement une valeur -- comme un
std::string -- et que tu le prend par référence pour des raisons de perf,
tu finis par avoir des bugs ou cet argument est modifié sans que tu t'y
attendes; l'alternative est de faire des copies inutiles dans 99% du temps.

[epsilon68]

Ça dépend de ton problème. T'es un manager ou quoi?

ta question est beaucoup plus complexe qu'elle en a l'air...

oui au boulot mais je ne fais plus vraiment de programmation depuis 1 an, en plus c'est du .NET ou Java /SQL, sachant que Java va approcher la ZERO utilisation (le marché a totalement changé en 3 ans)

non à la maison ou je m'eclate en C++/Qt

ma question était relative à mon utilisation perso, et à mon intérêt à Qt, qui était critiqué pour son utilisation du COW.

c'est juste que je voulais avoir un avis plus tranché et moins "ca depend de ton utilisation".

Pour être honnete, je n'arrive pas moi-même à être tranché sur le COW. J'aime bien que Qt l'utilise mais en fait le fait de separer l'interface des data donne beaucoup plus de boulot ... et c'est necessaire pour implementer le COW. Et en plus ca pose quelque difficulté pour l'heritage ...

bref c'est pas facile de se decider pour cette technique.
Pour le moment, je renvoie mes objets lourds (des objets 3D de centaine de Mo) avec des auto_ptr. Je pense que ce sera pareil pour mes collections, je n'arrive pas non plus à utiliser 100% de Qt, surement par souci d'independance

C'est pour ca que j'ai besoin de vos retours d'expérience, pour me conforter dans mes choix ou me faire changer ...

[Jean-Marc.Bourguet]

ta question est beaucoup plus complexe qu'elle en a l'air...

J'apprécie beaucoup l'humour de ta réponse.

c'est juste que je voulais avoir un avis plus tranché et moins "ca depend de ton utilisation".

Voir ce qu'a écrit Luc et ma réponse. Les cas où le COW semble utile nous semble avoir des problèmes de conceptions. En tout cas, ils n'arrivent pas avec les techniques de conceptions que nous employons.

[loufoque]

Ben c'est e que fait le COW. Sauf que le cow va copier si tu modifie une des occurentes.

Ça ne répond certainement pas aux sémantiques de partage, puisque le but c'est justement d'avoir une sémantique de copie.
Que ça utilise du partage comme détail d'implémentation, on s'en fout.

[yan]

Ça ne répond certainement pas aux sémantiques de partage, puisque le but c'est justement d'avoir une sémantique de copie.
Que ça utilise du partage comme détail d'implémentation, on s'en fout.

ben tu peut nommé comme tu veut (sémantiques de partage ou sémantique de copie), mais on s'en fou pas, la question c'est sur le cow.

Pour moi, le plus gros avantage est l'envoie d'objet entre thread.
Un signal emit d'une thread A peut être intercepté par une autre thread B.
Pour cela, une copie de l'objet doit être faite et envoyé avec le slot dans l'event loop de la thread B.

Le cow va permettre d'éviter, si possible, la copie inutile. C'est ce qui est fait dans cette exemple :
http://qt.developpez.com/doc/4.4/threads-mandelbrot/

Qt as tendance à protoger ce que font les utilisateur. Par exemple, le foreach de qt va copier le conteneur avant de le parcourir. Ca protège le parcoure. Sans le cow, ca ferai une copie probablement inutilise pour chaque élément du contenaire
http://qt.developpez.com/doc/4.4/con...oreach-keyword

Aprés c'est un choix. Mais pour moi c'est un bon compromis pour les différents utilisateurs de Qt. Car tout le monde ne peut pas penser à tout ou être aussi expérimenté que vous.

[yan]

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

Ben pour du code utilisant Qt,plustôt les conteneur de Qt. Sinon la stl.
Mais bon c'est quasiment la même chose.
http://www.developpez.net/forums/new...eply&p=3544631

[epsilon68]

Ben pour du code utilisant Qt,plustôt les conteneur de Qt. Sinon la stl.

et dans le cas de la STL, le COW ne te manque pas?
tu passes ta collection en parametre ou tu la retournes?

[loufoque]

Mongaulois, ce que tu ne comprends pas, c'est que le COW, ce n'est qu'une implémentation possible pour implémenter la sémantique valeur.
Que std::string fasse ou non du COW, on s'en fout. Pour l'utilisateur final, ça a le même comportement. Ça a juste des performances différentes.

Le problème, c'est que le COW ne permet d'optimiser que des erreurs de programmation, et ajoute un coût certain ; donc au final ce n'est pas une bonne optimisation.
C'est uniquement intéressant si on fait du COW partiel, et encore, ça dépend des cas.

[yan]

et dans le cas de la STL, le COW ne te manque pas?
tu passes ta collection en parametre ou tu la retournes?

J'ai appris sans. Mais j'aime beaucoup le principe du COW. Aprés, je n'ai pas assez d'expérience pour faire un vrai choix.

Mongaulois, ce que tu ne comprends pas, c'est que le COW, ce n'est qu'une implémentation possible pour implémenter la sémantique valeur.
Que std::string fasse ou non du COW, on s'en fout. Pour l'utilisateur final, ça a le même comportement. Ça a juste des performances différentes.

Ca je l'ai bien compris, et surtout grâce à ce thread. Mais la question pose sur le COW. Dire que l'on s'en fou c'est pas répondre ؟

Le problème, c'est que le COW ne permet d'optimiser que des erreurs de programmation, et ajoute un coût certain ; donc au final ce n'est pas une bonne optimisation.
C'est uniquement intéressant si on fait du COW partiel, et encore, ça dépend des cas.

C'est claire que ça va beaucoup optimiser les erreurs des programmeur. Mais même pour les autres(moi ?), ça évite certaine prise de tête. Je ne pense pas que c'est la solution miracle. Mais un bon compromis pour le public visée par trolltech.

Aprés côté perf, un bon contre exemple sont les accesseurs aux pixels d'une QImage. Si pour chaque pixel ont les utilisent ont as une trés fort perte de performance du à la vérification du référencement. Et il faut utiliser un pointeur pour parcourir le buffer de l'image....

[epsilon68]

Loufoque a raison, je crois que mon "probleme" venait de la semantique de copie.

Le COW ne va pas resoudre mes "problemes" pour mes gros objets, car de toute facon une logique de copie n'est pas bonne, pareille pour les collections.
Pour l'instant j'utilise un auto pointer ce qui me semble etre de mieux en mieux finalement.

Par contre pour Qt, je comprends leur choix, ils ont eliminé beaucoup de problemes pour les utilisateurs, et principalement dans les signals/slots je pense.

[JolyLoic]

Pour moi, le plus gros avantage est l'envoie d'objet entre thread.
Un signal emit d'une thread A peut être intercepté par une autre thread B.
Pour cela, une copie de l'objet doit être faite et envoyé avec le slot dans l'event loop de la thread B.

Je ne suis pas trop convaincu par cet exemple...
Quand je communique une donnée entre deux threads, je me trouve en général dans un de ces cas :
1/ Les deux threads vont travailler en lecture ou écriture sur la même donnée, qui a une sémantique d'entitée.
2/ Les deux threads vont travailler en lecture ou écriture sur à partir d'une même valeur.
3/ Les deux threads vont juste lire la donnée, pas la peine de se poser la question.

1/ s'implémente par un passage par référence/pointeur, et des locks là où il faut.
2/ s'implémente par un passage par copie
3/ s'implémente par un passage par référence constante.

L'intérêt du COW dans ce cas est d'avoir une implémentation unique pour le cas 2/ et le cas 3/. Je préfère pour ma part que le code m'indique clairement dans quel cas j'ai décidé de me placer.

[yan]

L'intérêt du COW dans ce cas est d'avoir une implémentation unique pour le cas 2/ et le cas 3/. Je préfère pour ma part que le code m'indique clairement dans quel cas j'ai décidé de me placer.

Y aura toujours d'autre manière (meilleur?!) de faire. Mais Qt (ou KDE? je ne sais pas qui viens en premier) as fait un choix que je trouve cohérent avec leur philosophie : simplifier la vie des programmeurs.

Si tu voie les class Qt comme une boite avec des entrée (slots) et des sorties (signaux), et que tu veut pouvoir interconnecter ces boites sans se soucier si chaque boite est dans la même thread ou non. Je trouve que le cow est un bon compromis. Si la partie partagé va être modifié, il y aura une copie. Sinon se sera comme un shared_ptr. Le développeur se pose moins de question.

Y as une autre subtilité, ou le cow est utile pour éviter une copie peut être inutile, mais qui me dérange un peu.
Si tu créé un signal avec une référence constante et qu'un slot d'un objet d'une autre thread est connecté, l'objet sera copié pour être envoyé dans l'event loop de la thread. C'est la copie qui me dérange... D'un côté il n'y as pas trop le choix comme l'objet sera utilisé à un autre instant, mais la copie est totalement implicite... D'ailleur c'est pour cela qu'utiliser une référence non const est interdit dans un signal ou un slot.

[HanLee]

Y aura toujours d'autre manière (meilleur?!) de faire. Mais Qt (ou KDE? je ne sais pas qui viens en premier) as fait un choix que je trouve cohérent avec leur philosophie : simplifier la vie des programmeurs.

Si tu voie les class Qt comme une boite avec des entrée (slots) et des sorties (signaux), et que tu veut pouvoir interconnecter ces boites sans se soucier si chaque boite est dans la même thread ou non. Je trouve que le cow est un bon compromis. Si la partie partagé va être modifié, il y aura une copie. Sinon se sera comme un shared_ptr. Le développeur se pose moins de question.

Y as une autre subtilité, ou le cow est utile pour éviter une copie peut être inutile, mais qui me dérange un peu.
Si tu créé un signal avec une référence constante et qu'un slot d'un objet d'une autre thread est connecté, l'objet sera copié pour être envoyé dans l'event loop de la thread. C'est la copie qui me dérange... D'un côté il n'y as pas trop le choix comme l'objet sera utilisé à un autre instant, mais la copie est totalement implicite... D'ailleur c'est pour cela qu'utiliser une référence non const est interdit dans un signal ou un slot.

Là quand même, je suis d'accord.

Tous les arguments qui disent qu'on a pas besoin du COW, j'suis d'accord.

Mais après, il faut avouer que d'un point de vue ingénieur (et pas d'un informaticien), le COW est un très bon truc. Il donne des perfs excellentes (pas forcément optimales), et il simplifie la vie, au prix d'une sémantique peut être moins claire, mais si la doc va avec (et c'est vraisemblable qu'elle vienne avec, vu que comment le multi-thread est source de problème, non ?).

[epsilon68]

mais le COW sauve-t-il reellement de la mémoire?