Je viens de voir Ceci Nice Pointeur de copie-écriture implémentation. Il a l'air assez générique et utile, alors ma question est la suivante: une telle classe contenue dans l'une quelconque des outils à outils C ++ (Boost, Loki, etc.)? Si non, j'aimerais vraiment savoir pourquoi parce que c'est une idiome vraiment utile et apparemment une implémentation générique semble être faisable (comme celle que j'ai liée à).
3 Réponses :
Il y avait beaucoup de débat sur la possibilité, et au moins une version suggérée de ce qui finit par être sorti comme Malheureusement, le temps de la vache a principalement passé. Faire un pointeur de vache (ou une vache-size) peut introduire sérieux Problèmes de performance .
Edit: relire que, je me sens obligé de souligner que pas tous les l'utilisation de vache nécessairement obsolète. Il y a des moments où cela a toujours du sens. Les frais généraux d'un incrément de fil-sécurité sont à peu près fixés - il n'est donc qu'une question de savoir comment un objet important doit être important ou à quel point il est cher à copier, pour une vache pour avoir un sens. Il y a aussi des temps / endroits que vous avez lots de copies d'un objet (non modifié) et que les économies de mémoire peuvent constituer un compromis raisonnable - les économies en mémoire justifient un temps de processeur supplémentaire. Si vous pouvez économiser des données Little Data vers / Of Disk, vous pouvez venir à l'avance à la hâte. auto_ptr était pour un pointeur de vache compté de référence.
@Frank: triste? Comment? Cela ne conduit tout simplement pas à un code plus rapide, alors pourquoi l'utiliser?
Comme Jerry Coffin a déclaré qu'il a été démontré que la vache Idiom a introduit des problèmes de performance ... mais il y a en réalité un autre problème.
Il n'est pas possible (comme démontré dans l'article même que vous liez à) pour écrire un générique Mise en œuvre de vache. Dans la mise en œuvre de la vache de Par exemple, supposons que je le fais: oupe! Je fais une copie de l'objet foo même s'il ne sera pas modifié! Le problème est que pendant que cette classe de vache aide, vous devez en réalité envelopper: puis méthodes de FOO qui modifie vraiment l'objet sera responsable de la copie de l'état et tout ce problème ... sans être sûr de gagner des performances en raison des problèmes de synchronisation dans une application MT ... N'a-t-il pas plus simple d'éviter de copier dans la mesure du possible (en utilisant des références / des pointeurs) plutôt que de modifier votre classe pour un gain possible dans certaines situations qui pénaliseront des utilisateurs qui ont déjà pris soin des problèmes de performances? std :: string La copie est effectuée chaque fois qu'une opération est invoquée qui modifiera en réalité l'état de la chaîne. Cependant, comment un pointeur est-il censé savoir que? Il n'a aucune connaissance sur la classe qu'il pointe. FOOIMPL . Tellement sûr que la classe aide, mais ce n'est pas une balle d'argent non plus.
Il existe une contradiction entre "pointeur" et "copie sur écriture": par définition, la déséroférance d'un pointeur ne le change pas et la modification Un pointeur de const peut donc être déréférencé et le lvalue résultant peut être modifiable.
Vous parlez vraiment d'un conteneur d'un élément, pas d'un pointeur. * p ne change pas p .
Il est contenu dans la boîte à outils QT et appelé
qshareddatapointer . C'est assez sympa.