Une de mes classes contient, entre autres, un vector sur une structure de
données. Ces données sont rarement modifiées, par contre les instances de
cette classe sont fréquemment copiées.
Je pensais donc à utiliser un objet boost::shared_ptr pour gérer ce vecteur,
et éventuellement implémenter une sorte de "copy-on-write", soit au niveau
des méthodes modifiant mes données, soit en trouvant une autre idée...
Ma première question est: est-ce que std::vector fait déjà ça lors de la
copie vector1=vector2 ? Je ne le crois pas, mais autant en être certain
avant de commencer ...
Certaines implémentations de la librairie standard pourraient-elles le
faire ? Dans ce cas ce n'est peut-être pas très judicieux d'utiliser
std::vector géré par un shared_ptr ?
Merci d'avance pour ces précisions. Toute remarque est également la
bienvenue ;-)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
espie
In article <44eed01e$0$12812$, Adrien wrote:
Bonjour,
Une de mes classes contient, entre autres, un vector sur une structure de données. Ces données sont rarement modifiées, par contre les instances de cette classe sont fréquemment copiées. Je pensais donc à utiliser un objet boost::shared_ptr pour gérer ce vecteur, et éventuellement implémenter une sorte de "copy-on-write", soit au niveau des méthodes modifiant mes données, soit en trouvant une autre idée...
Ma première question est: est-ce que std::vector fait déjà ça lors de la copie vector1=vector2 ? Je ne le crois pas, mais autant en être certain avant de commencer ... Certaines implémentations de la librairie standard pourraient-elles le faire ? Dans ce cas ce n'est peut-être pas très judicieux d'utiliser std::vector géré par un shared_ptr ?
Je ne suis pas parfaitement sur de la question, mais je pense pouvoir apporter des complements d'information.
- les containers de la bibliotheque standard supposent une semantique de copie au niveau des objets contenus. Ce qui est range dans un vecteur est copie lors d'une operation d'affectation, ou de recopie. La gestion en interne est `opaque', l'utilisateur n'a pas vraiment a savoir combien de copies sont faites lorsqu'on se trimbale des elements de vecteur en interne. C'est pour ca qu'on ne peut pas faire de container d'auto_ptr, par exemple. (si tu preferes, les elements des vecteurs doivent avoir une semantique de valeur).
- il existe une operation atomique qui permet de remplacer le contenu d'un vecteur par un autre, c'est swap. Elle est explicitement prevue pour resoudre tout un ensemble de problemes epineux. Voir entre autres les ecrits d'Herb Sutter, je ne sais plus si c'est dans _exceptional C++_ ou _more exceptional C++_, mais c'est extremement utile pour resoudre plein de types de probleme.
Si j'ai bien compris, shared_ptr serait effectivement approprie dans ton cas de figure.
In article <44eed01e$0$12812$626a54ce@news.free.fr>,
Adrien <adrien-news@wizzi.net> wrote:
Bonjour,
Une de mes classes contient, entre autres, un vector sur une structure de
données. Ces données sont rarement modifiées, par contre les instances de
cette classe sont fréquemment copiées.
Je pensais donc à utiliser un objet boost::shared_ptr pour gérer ce vecteur,
et éventuellement implémenter une sorte de "copy-on-write", soit au niveau
des méthodes modifiant mes données, soit en trouvant une autre idée...
Ma première question est: est-ce que std::vector fait déjà ça lors de la
copie vector1=vector2 ? Je ne le crois pas, mais autant en être certain
avant de commencer ...
Certaines implémentations de la librairie standard pourraient-elles le
faire ? Dans ce cas ce n'est peut-être pas très judicieux d'utiliser
std::vector géré par un shared_ptr ?
Je ne suis pas parfaitement sur de la question, mais je pense pouvoir
apporter des complements d'information.
- les containers de la bibliotheque standard supposent une semantique
de copie au niveau des objets contenus. Ce qui est range dans un vecteur
est copie lors d'une operation d'affectation, ou de recopie. La gestion
en interne est `opaque', l'utilisateur n'a pas vraiment a savoir combien
de copies sont faites lorsqu'on se trimbale des elements de vecteur en
interne. C'est pour ca qu'on ne peut pas faire de container d'auto_ptr,
par exemple. (si tu preferes, les elements des vecteurs doivent avoir
une semantique de valeur).
- il existe une operation atomique qui permet de remplacer le contenu d'un
vecteur par un autre, c'est swap. Elle est explicitement prevue pour
resoudre tout un ensemble de problemes epineux. Voir entre autres les
ecrits d'Herb Sutter, je ne sais plus si c'est dans _exceptional C++_
ou _more exceptional C++_, mais c'est extremement utile pour resoudre
plein de types de probleme.
Si j'ai bien compris, shared_ptr serait effectivement approprie dans
ton cas de figure.
Une de mes classes contient, entre autres, un vector sur une structure de données. Ces données sont rarement modifiées, par contre les instances de cette classe sont fréquemment copiées. Je pensais donc à utiliser un objet boost::shared_ptr pour gérer ce vecteur, et éventuellement implémenter une sorte de "copy-on-write", soit au niveau des méthodes modifiant mes données, soit en trouvant une autre idée...
Ma première question est: est-ce que std::vector fait déjà ça lors de la copie vector1=vector2 ? Je ne le crois pas, mais autant en être certain avant de commencer ... Certaines implémentations de la librairie standard pourraient-elles le faire ? Dans ce cas ce n'est peut-être pas très judicieux d'utiliser std::vector géré par un shared_ptr ?
Je ne suis pas parfaitement sur de la question, mais je pense pouvoir apporter des complements d'information.
- les containers de la bibliotheque standard supposent une semantique de copie au niveau des objets contenus. Ce qui est range dans un vecteur est copie lors d'une operation d'affectation, ou de recopie. La gestion en interne est `opaque', l'utilisateur n'a pas vraiment a savoir combien de copies sont faites lorsqu'on se trimbale des elements de vecteur en interne. C'est pour ca qu'on ne peut pas faire de container d'auto_ptr, par exemple. (si tu preferes, les elements des vecteurs doivent avoir une semantique de valeur).
- il existe une operation atomique qui permet de remplacer le contenu d'un vecteur par un autre, c'est swap. Elle est explicitement prevue pour resoudre tout un ensemble de problemes epineux. Voir entre autres les ecrits d'Herb Sutter, je ne sais plus si c'est dans _exceptional C++_ ou _more exceptional C++_, mais c'est extremement utile pour resoudre plein de types de probleme.
Si j'ai bien compris, shared_ptr serait effectivement approprie dans ton cas de figure.
Adrien
Marc Espie wrote:
Je ne suis pas parfaitement sur de la question, mais je pense pouvoir apporter des complements d'information.
- les containers de la bibliotheque standard supposent une semantique de copie au niveau des objets contenus. Ce qui est range dans un vecteur est copie lors d'une operation d'affectation, ou de recopie. La gestion en interne est `opaque', l'utilisateur n'a pas vraiment a savoir combien de copies sont faites lorsqu'on se trimbale des elements de vecteur en interne. C'est pour ca qu'on ne peut pas faire de container d'auto_ptr, par exemple. (si tu preferes, les elements des vecteurs doivent avoir une semantique de valeur).
- il existe une operation atomique qui permet de remplacer le contenu d'un vecteur par un autre, c'est swap. Elle est explicitement prevue pour resoudre tout un ensemble de problemes epineux. Voir entre autres les ecrits d'Herb Sutter, je ne sais plus si c'est dans _exceptional C++_ ou _more exceptional C++_, mais c'est extremement utile pour resoudre plein de types de probleme.
Si j'ai bien compris, shared_ptr serait effectivement approprie dans ton cas de figure.
Merci Marc.
Marc Espie wrote:
Je ne suis pas parfaitement sur de la question, mais je pense pouvoir
apporter des complements d'information.
- les containers de la bibliotheque standard supposent une semantique
de copie au niveau des objets contenus. Ce qui est range dans un vecteur
est copie lors d'une operation d'affectation, ou de recopie. La gestion
en interne est `opaque', l'utilisateur n'a pas vraiment a savoir combien
de copies sont faites lorsqu'on se trimbale des elements de vecteur en
interne. C'est pour ca qu'on ne peut pas faire de container d'auto_ptr,
par exemple. (si tu preferes, les elements des vecteurs doivent avoir
une semantique de valeur).
- il existe une operation atomique qui permet de remplacer le contenu d'un
vecteur par un autre, c'est swap. Elle est explicitement prevue pour
resoudre tout un ensemble de problemes epineux. Voir entre autres les
ecrits d'Herb Sutter, je ne sais plus si c'est dans _exceptional C++_
ou _more exceptional C++_, mais c'est extremement utile pour resoudre
plein de types de probleme.
Si j'ai bien compris, shared_ptr serait effectivement approprie dans
ton cas de figure.
Je ne suis pas parfaitement sur de la question, mais je pense pouvoir apporter des complements d'information.
- les containers de la bibliotheque standard supposent une semantique de copie au niveau des objets contenus. Ce qui est range dans un vecteur est copie lors d'une operation d'affectation, ou de recopie. La gestion en interne est `opaque', l'utilisateur n'a pas vraiment a savoir combien de copies sont faites lorsqu'on se trimbale des elements de vecteur en interne. C'est pour ca qu'on ne peut pas faire de container d'auto_ptr, par exemple. (si tu preferes, les elements des vecteurs doivent avoir une semantique de valeur).
- il existe une operation atomique qui permet de remplacer le contenu d'un vecteur par un autre, c'est swap. Elle est explicitement prevue pour resoudre tout un ensemble de problemes epineux. Voir entre autres les ecrits d'Herb Sutter, je ne sais plus si c'est dans _exceptional C++_ ou _more exceptional C++_, mais c'est extremement utile pour resoudre plein de types de probleme.
Si j'ai bien compris, shared_ptr serait effectivement approprie dans ton cas de figure.
Merci Marc.
kanze
Adrien wrote:
Une de mes classes contient, entre autres, un vector sur une structure de données. Ces données sont rarement modifiées, par contre les instances de cette classe sont fréquemment copiées. Je pensais donc à utiliser un objet boost::shared_ptr pour gérer ce vecteur, et éventuellement implémenter une sorte de "copy-on-write", soit au niveau des méthodes modifiant mes données, soit en trouvant une autre idée...
Ma première question est: est-ce que std::vector fait déjà ça lors de la copie vector1=vector2 ? Je ne le crois pas, mais autant en être certain avant de commencer ... Certaines implémentations de la librairie standard pourraient-elles le faire ?
En principe, la norme ne dit pas comment est implémenté une classe. Dans les faits, il y a quand même des limitations dues aux contraintes. Dans le cas de std::vector, par exemple, il y a le fait que la modification d'un élément n'invalide pas les itérateurs ni les référennces des éléments restants dans le vecteur. Ce qui rend une implémentation COW quasiment impossible, considère :
Note que le cas avec std::string est légèrement différent : si on avait eu des std::string à la place des std::vector< int >, l'opération [] (sur un objet non-const) aurait invalidé les pointeurs, et toute utilisation de p1 ou de p2 par la suite aurait eu un comportement indéfini. Ce qui n'est pas le cas de std::vector.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Adrien wrote:
Une de mes classes contient, entre autres, un vector sur une
structure de données. Ces données sont rarement modifiées, par
contre les instances de cette classe sont fréquemment copiées.
Je pensais donc à utiliser un objet boost::shared_ptr pour
gérer ce vecteur, et éventuellement implémenter une sorte de
"copy-on-write", soit au niveau des méthodes modifiant mes
données, soit en trouvant une autre idée...
Ma première question est: est-ce que std::vector fait déjà ça
lors de la copie vector1=vector2 ? Je ne le crois pas, mais
autant en être certain avant de commencer ...
Certaines implémentations de la librairie standard pourraient-elles le
faire ?
En principe, la norme ne dit pas comment est implémenté une
classe. Dans les faits, il y a quand même des limitations dues
aux contraintes. Dans le cas de std::vector, par exemple, il y a
le fait que la modification d'un élément n'invalide pas les
itérateurs ni les référennces des éléments restants dans le
vecteur. Ce qui rend une implémentation COW quasiment
impossible, considère :
Note que le cas avec std::string est légèrement différent : si
on avait eu des std::string à la place des std::vector< int >,
l'opération [] (sur un objet non-const) aurait invalidé les
pointeurs, et toute utilisation de p1 ou de p2 par la suite
aurait eu un comportement indéfini. Ce qui n'est pas le cas de
std::vector.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Une de mes classes contient, entre autres, un vector sur une structure de données. Ces données sont rarement modifiées, par contre les instances de cette classe sont fréquemment copiées. Je pensais donc à utiliser un objet boost::shared_ptr pour gérer ce vecteur, et éventuellement implémenter une sorte de "copy-on-write", soit au niveau des méthodes modifiant mes données, soit en trouvant une autre idée...
Ma première question est: est-ce que std::vector fait déjà ça lors de la copie vector1=vector2 ? Je ne le crois pas, mais autant en être certain avant de commencer ... Certaines implémentations de la librairie standard pourraient-elles le faire ?
En principe, la norme ne dit pas comment est implémenté une classe. Dans les faits, il y a quand même des limitations dues aux contraintes. Dans le cas de std::vector, par exemple, il y a le fait que la modification d'un élément n'invalide pas les itérateurs ni les référennces des éléments restants dans le vecteur. Ce qui rend une implémentation COW quasiment impossible, considère :
Note que le cas avec std::string est légèrement différent : si on avait eu des std::string à la place des std::vector< int >, l'opération [] (sur un objet non-const) aurait invalidé les pointeurs, et toute utilisation de p1 ou de p2 par la suite aurait eu un comportement indéfini. Ce qui n'est pas le cas de std::vector.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Marc Espie wrote:
In article <44eed01e$0$12812$, Adrien wrote:
[...]
- les containers de la bibliotheque standard supposent une semantique de copie au niveau des objets contenus. Ce qui est range dans un vecteur est copie lors d'une operation d'affectation, ou de recopie. La gestion en interne est `opaque', l'utilisateur n'a pas vraiment a savoir combien de copies sont faites lorsqu'on se trimbale des elements de vecteur en interne.
Ce n'est pas tout à fait vrai. Il y a des contraintes au niveau de la complexité (mesurée en termes d'appels aux constructeurs et à l'opérateur d'affectation de T) -- pour erase, par exemple, la norme dit :
The destructor of T is called the number of times equal to the number of elements erased, but the assignment operator of T is called the number of times equal to the number of elements in the vector after the erased documents.
Note que cette contrainte signifie, parmi d'autre chose, que je ne peux pas faire une copie de tous les éléments lors d'un pop_back (qui est défini en termes d'erase). Ce qui empêche l'utilisation de COW aussi.
Ce qui est certain, c'est que tout élément dans le vector, à chaque moment, doit être Copiable et Assignable. Mais il y a quand même des limites sur ce que peut faire l'implémentation, et il ne faut pas imaginer qu'il pourrait copier n'importe comment.
C'est pour ca qu'on ne peut pas faire de container d'auto_ptr, par exemple. (si tu preferes, les elements des vecteurs doivent avoir une semantique de valeur).
- il existe une operation atomique qui permet de remplacer le contenu d'un vecteur par un autre, c'est swap. Elle est explicitement prevue pour resoudre tout un ensemble de problemes epineux.
Pour resoudre à certains problèmes épineux. Si on veut avoir trois ou quatre copies du même vector, quitte à en modifier une par la suite, il n'aide en rien. (Pour emprunter un vocabulaire assez en vogue dans la communité C++ en ce moment, il aide à simuler une sémantique de move, qu'on n'a pas autrement en C++. En somme, il est surtout utile quand un des vector va être détruit tout de suite après.)
[...]
Si j'ai bien compris, shared_ptr serait effectivement approprie dans ton cas de figure.
C'est à peu près ce que je pense aussi.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Marc Espie wrote:
In article <44eed01e$0$12812$626a54ce@news.free.fr>,
Adrien <adrien-news@wizzi.net> wrote:
[...]
- les containers de la bibliotheque standard supposent une semantique
de copie au niveau des objets contenus. Ce qui est range dans un vecteur
est copie lors d'une operation d'affectation, ou de recopie. La gestion
en interne est `opaque', l'utilisateur n'a pas vraiment a savoir combien
de copies sont faites lorsqu'on se trimbale des elements de vecteur en
interne.
Ce n'est pas tout à fait vrai. Il y a des contraintes au niveau
de la complexité (mesurée en termes d'appels aux constructeurs
et à l'opérateur d'affectation de T) -- pour erase, par
exemple, la norme dit :
The destructor of T is called the number of times equal to
the number of elements erased, but the assignment operator
of T is called the number of times equal to the number of
elements in the vector after the erased documents.
Note que cette contrainte signifie, parmi d'autre chose, que je
ne peux pas faire une copie de tous les éléments lors d'un
pop_back (qui est défini en termes d'erase). Ce qui empêche
l'utilisation de COW aussi.
Ce qui est certain, c'est que tout élément dans le vector, à
chaque moment, doit être Copiable et Assignable. Mais il y a
quand même des limites sur ce que peut faire l'implémentation,
et il ne faut pas imaginer qu'il pourrait copier n'importe
comment.
C'est pour ca qu'on ne peut pas faire de container d'auto_ptr,
par exemple. (si tu preferes, les elements des vecteurs doivent avoir
une semantique de valeur).
- il existe une operation atomique qui permet de remplacer le
contenu d'un vecteur par un autre, c'est swap. Elle est
explicitement prevue pour resoudre tout un ensemble de
problemes epineux.
Pour resoudre à certains problèmes épineux. Si on veut avoir
trois ou quatre copies du même vector, quitte à en modifier une
par la suite, il n'aide en rien. (Pour emprunter un vocabulaire
assez en vogue dans la communité C++ en ce moment, il aide à
simuler une sémantique de move, qu'on n'a pas autrement en C++.
En somme, il est surtout utile quand un des vector va être
détruit tout de suite après.)
[...]
Si j'ai bien compris, shared_ptr serait effectivement
approprie dans ton cas de figure.
C'est à peu près ce que je pense aussi.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
- les containers de la bibliotheque standard supposent une semantique de copie au niveau des objets contenus. Ce qui est range dans un vecteur est copie lors d'une operation d'affectation, ou de recopie. La gestion en interne est `opaque', l'utilisateur n'a pas vraiment a savoir combien de copies sont faites lorsqu'on se trimbale des elements de vecteur en interne.
Ce n'est pas tout à fait vrai. Il y a des contraintes au niveau de la complexité (mesurée en termes d'appels aux constructeurs et à l'opérateur d'affectation de T) -- pour erase, par exemple, la norme dit :
The destructor of T is called the number of times equal to the number of elements erased, but the assignment operator of T is called the number of times equal to the number of elements in the vector after the erased documents.
Note que cette contrainte signifie, parmi d'autre chose, que je ne peux pas faire une copie de tous les éléments lors d'un pop_back (qui est défini en termes d'erase). Ce qui empêche l'utilisation de COW aussi.
Ce qui est certain, c'est que tout élément dans le vector, à chaque moment, doit être Copiable et Assignable. Mais il y a quand même des limites sur ce que peut faire l'implémentation, et il ne faut pas imaginer qu'il pourrait copier n'importe comment.
C'est pour ca qu'on ne peut pas faire de container d'auto_ptr, par exemple. (si tu preferes, les elements des vecteurs doivent avoir une semantique de valeur).
- il existe une operation atomique qui permet de remplacer le contenu d'un vecteur par un autre, c'est swap. Elle est explicitement prevue pour resoudre tout un ensemble de problemes epineux.
Pour resoudre à certains problèmes épineux. Si on veut avoir trois ou quatre copies du même vector, quitte à en modifier une par la suite, il n'aide en rien. (Pour emprunter un vocabulaire assez en vogue dans la communité C++ en ce moment, il aide à simuler une sémantique de move, qu'on n'a pas autrement en C++. En somme, il est surtout utile quand un des vector va être détruit tout de suite après.)
[...]
Si j'ai bien compris, shared_ptr serait effectivement approprie dans ton cas de figure.
C'est à peu près ce que je pense aussi.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
loufoque
Je pensais donc à utiliser un objet boost::shared_ptr pour gérer ce vecteur, et éventuellement implémenter une sorte de "copy-on-write", soit au niveau des méthodes modifiant mes données, soit en trouvant une autre idée...
Il me semble que le clone_ptr de boost a une option pour faire du COW. Ça a l'avantage d'avoir des sémantiques de valeur, contrairement à shared_ptr.
Je pensais donc à utiliser un objet boost::shared_ptr pour gérer ce vecteur,
et éventuellement implémenter une sorte de "copy-on-write", soit au niveau
des méthodes modifiant mes données, soit en trouvant une autre idée...
Il me semble que le clone_ptr de boost a une option pour faire du COW.
Ça a l'avantage d'avoir des sémantiques de valeur, contrairement à
shared_ptr.
Je pensais donc à utiliser un objet boost::shared_ptr pour gérer ce vecteur, et éventuellement implémenter une sorte de "copy-on-write", soit au niveau des méthodes modifiant mes données, soit en trouvant une autre idée...
Il me semble que le clone_ptr de boost a une option pour faire du COW. Ça a l'avantage d'avoir des sémantiques de valeur, contrairement à shared_ptr.
kanze
loufoque wrote:
Je pensais donc à utiliser un objet boost::shared_ptr pour gérer ce vecteur, et éventuellement implémenter une sorte de "copy-on-write", soit au niveau des méthodes modifiant mes données, soit en trouvant une autre idée...
Il me semble que le clone_ptr de boost a une option pour faire du COW. Ça a l'avantage d'avoir des sémantiques de valeur, contrairement à shared_ptr.
Il me semble justement qu'à cause de sa sémantique de valeur, il ne pourrait servir pour faire du COW. Il fait la copie profonde tout de suite, je crois. (C'est de toute façon ce que son nom ferait croire.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
loufoque wrote:
Je pensais donc à utiliser un objet boost::shared_ptr pour
gérer ce vecteur, et éventuellement implémenter une sorte de
"copy-on-write", soit au niveau des méthodes modifiant mes
données, soit en trouvant une autre idée...
Il me semble que le clone_ptr de boost a une option pour faire
du COW. Ça a l'avantage d'avoir des sémantiques de valeur,
contrairement à shared_ptr.
Il me semble justement qu'à cause de sa sémantique de valeur, il
ne pourrait servir pour faire du COW. Il fait la copie profonde
tout de suite, je crois. (C'est de toute façon ce que son nom
ferait croire.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Je pensais donc à utiliser un objet boost::shared_ptr pour gérer ce vecteur, et éventuellement implémenter une sorte de "copy-on-write", soit au niveau des méthodes modifiant mes données, soit en trouvant une autre idée...
Il me semble que le clone_ptr de boost a une option pour faire du COW. Ça a l'avantage d'avoir des sémantiques de valeur, contrairement à shared_ptr.
Il me semble justement qu'à cause de sa sémantique de valeur, il ne pourrait servir pour faire du COW. Il fait la copie profonde tout de suite, je crois. (C'est de toute façon ce que son nom ferait croire.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
loufoque
Il me semble justement qu'à cause de sa sémantique de valeur, il ne pourrait servir pour faire du COW.
En fait, je voulais dire clone-on-copy. La sémantique de valeur n'est qu'une interface. Comment cela fonctionne derrière est indépendant.
Voir http://article.gmane.org/gmane.comp.lib.boost.devel/145166/match=clone+ptr+library qui dit, je cite :
"Also, I've decided to give clone_ptr clone-on-write semantics instead of clone-on-copy. This should alleviate any concerns about performance when inserting into a std::vector or copying containers (copying clone_ptr would give similar performance to boost::shared_ptr)."
Il me semble justement qu'à cause de sa sémantique de valeur, il
ne pourrait servir pour faire du COW.
En fait, je voulais dire clone-on-copy.
La sémantique de valeur n'est qu'une interface.
Comment cela fonctionne derrière est indépendant.
Voir
http://article.gmane.org/gmane.comp.lib.boost.devel/145166/match=clone+ptr+library
qui dit, je cite :
"Also, I've decided to give clone_ptr clone-on-write semantics instead of
clone-on-copy. This should alleviate any concerns about performance when
inserting into a std::vector or copying containers (copying clone_ptr would
give similar performance to boost::shared_ptr)."
Il me semble justement qu'à cause de sa sémantique de valeur, il ne pourrait servir pour faire du COW.
En fait, je voulais dire clone-on-copy. La sémantique de valeur n'est qu'une interface. Comment cela fonctionne derrière est indépendant.
Voir http://article.gmane.org/gmane.comp.lib.boost.devel/145166/match=clone+ptr+library qui dit, je cite :
"Also, I've decided to give clone_ptr clone-on-write semantics instead of clone-on-copy. This should alleviate any concerns about performance when inserting into a std::vector or copying containers (copying clone_ptr would give similar performance to boost::shared_ptr)."
