Je suis en train de lire le "Design & Evolution of C++",
et j'ai un problème. Au $3.7.1, Stroustrup décrit un
problème: comment distinguer un accès en lecture et en
écriture avec l'opérateur [].
Pour situer, l'idée c'est pouvoir différencier un accès
en lecture et en écriture.
Moi, j'utilisais juste deux méthodes différentes
char const & operator[](int i) const;
char & operator[](int i);
mais lui passe par une classe intermédiaire.
C'est juste parce qu'il parle d'une époque où il n'y
avait pas de const, ou il y a une faille dans mon
approche que je ne vois pas ?
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
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
amerio
Je suis en train de lire le "Design & Evolution of C++", et j'ai un problème. Au $3.7.1, Stroustrup décrit un problème: comment distinguer un accès en lecture et en écriture avec l'opérateur [].
Pour situer, l'idée c'est pouvoir différencier un accès en lecture et en écriture.
Moi, j'utilisais juste deux méthodes différentes char const & operator[](int i) const; char & operator[](int i); mais lui passe par une classe intermédiaire.
C'est juste parce qu'il parle d'une époque où il n'y avait pas de const, ou il y a une faille dans mon approche que je ne vois pas ?
Il y a une faille. Mettre un accesseur en const garantit juste que cette accesseur sera appéle si l'objet est const. Mais sur un objet non-const, même pour un accés en lecture, c'est l'accesseur non-const qui sera appelé. D'ou l'idée répandu de passé par un "proxy", cad une classe intermédiaire.
Je suis en train de lire le "Design & Evolution of C++",
et j'ai un problème. Au $3.7.1, Stroustrup décrit un
problème: comment distinguer un accès en lecture et en
écriture avec l'opérateur [].
Pour situer, l'idée c'est pouvoir différencier un accès
en lecture et en écriture.
Moi, j'utilisais juste deux méthodes différentes
char const & operator[](int i) const;
char & operator[](int i);
mais lui passe par une classe intermédiaire.
C'est juste parce qu'il parle d'une époque où il n'y
avait pas de const, ou il y a une faille dans mon
approche que je ne vois pas ?
Il y a une faille.
Mettre un accesseur en const garantit juste que cette accesseur sera appéle si l'objet est
const.
Mais sur un objet non-const, même pour un accés en lecture, c'est l'accesseur non-const
qui sera appelé.
D'ou l'idée répandu de passé par un "proxy", cad une classe intermédiaire.
Je suis en train de lire le "Design & Evolution of C++", et j'ai un problème. Au $3.7.1, Stroustrup décrit un problème: comment distinguer un accès en lecture et en écriture avec l'opérateur [].
Pour situer, l'idée c'est pouvoir différencier un accès en lecture et en écriture.
Moi, j'utilisais juste deux méthodes différentes char const & operator[](int i) const; char & operator[](int i); mais lui passe par une classe intermédiaire.
C'est juste parce qu'il parle d'une époque où il n'y avait pas de const, ou il y a une faille dans mon approche que je ne vois pas ?
Il y a une faille. Mettre un accesseur en const garantit juste que cette accesseur sera appéle si l'objet est const. Mais sur un objet non-const, même pour un accés en lecture, c'est l'accesseur non-const qui sera appelé. D'ou l'idée répandu de passé par un "proxy", cad une classe intermédiaire.
Marc Boyer
In article <pHafb.14613$, amerio wrote:
Il y a une faille. Mettre un accesseur en const garantit juste que cette accesseur sera appéle si l'objet est const. Mais sur un objet non-const, même pour un accés en lecture, c'est l'accesseur non-const qui sera appelé. D'ou l'idée répandu de passé par un "proxy", cad une classe intermédiaire.
OK... Merci.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
In article <pHafb.14613$qU6.207087@news.chello.at>, amerio wrote:
Il y a une faille.
Mettre un accesseur en const garantit juste que cette accesseur sera appéle si l'objet est
const.
Mais sur un objet non-const, même pour un accés en lecture, c'est l'accesseur non-const
qui sera appelé.
D'ou l'idée répandu de passé par un "proxy", cad une classe intermédiaire.
OK... Merci.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Il y a une faille. Mettre un accesseur en const garantit juste que cette accesseur sera appéle si l'objet est const. Mais sur un objet non-const, même pour un accés en lecture, c'est l'accesseur non-const qui sera appelé. D'ou l'idée répandu de passé par un "proxy", cad une classe intermédiaire.
OK... Merci.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Gabriel Dos Reis
Marc Boyer writes:
| Je suis en train de lire le "Design & Evolution of C++",
interessant ouvrage, n'est-ec pas ? :-)
| et j'ai un problème. Au $3.7.1, Stroustrup décrit un | problème: comment distinguer un accès en lecture et en | écriture avec l'opérateur []. | | Pour situer, l'idée c'est pouvoir différencier un accès | en lecture et en écriture. | | Moi, j'utilisais juste deux méthodes différentes | char const & operator[](int i) const; | char & operator[](int i); | mais lui passe par une classe intermédiaire. | | C'est juste parce qu'il parle d'une époque où il n'y | avait pas de const, ou il y a une faille dans mon | approche que je ne vois pas ?
Une faille (classique) dans ton raisonnement.
Supposons
struct A { const char& operator[](int) const; char& operator[](int); };
A a;
char c = a[4];
Pour déterminer quelle operator[] appeler, il faut faire une résolution de surcharge. Pour des raisons de commodité d'écriture, on va réecire les fonctions comme
la fonction #1 réalise un best macth, alors que pour appeler #2 il faut faire une cv-qualification conversion pour l'argument "&a". Une telle transformation est toujours moins bien que la transformation identité, donc la résolution de surcharge prochame la fonction #1 lauréate du tournoi.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| Je suis en train de lire le "Design & Evolution of C++",
interessant ouvrage, n'est-ec pas ? :-)
| et j'ai un problème. Au $3.7.1, Stroustrup décrit un
| problème: comment distinguer un accès en lecture et en
| écriture avec l'opérateur [].
|
| Pour situer, l'idée c'est pouvoir différencier un accès
| en lecture et en écriture.
|
| Moi, j'utilisais juste deux méthodes différentes
| char const & operator[](int i) const;
| char & operator[](int i);
| mais lui passe par une classe intermédiaire.
|
| C'est juste parce qu'il parle d'une époque où il n'y
| avait pas de const, ou il y a une faille dans mon
| approche que je ne vois pas ?
Une faille (classique) dans ton raisonnement.
Supposons
struct A {
const char& operator[](int) const;
char& operator[](int);
};
A a;
char c = a[4];
Pour déterminer quelle operator[] appeler, il faut faire une
résolution de surcharge. Pour des raisons de commodité d'écriture, on
va réecire les fonctions comme
la fonction #1 réalise un best macth, alors que pour appeler #2 il faut
faire une cv-qualification conversion pour l'argument "&a".
Une telle transformation est toujours moins bien que la transformation
identité, donc la résolution de surcharge prochame la fonction #1
lauréate du tournoi.
| Je suis en train de lire le "Design & Evolution of C++",
interessant ouvrage, n'est-ec pas ? :-)
| et j'ai un problème. Au $3.7.1, Stroustrup décrit un | problème: comment distinguer un accès en lecture et en | écriture avec l'opérateur []. | | Pour situer, l'idée c'est pouvoir différencier un accès | en lecture et en écriture. | | Moi, j'utilisais juste deux méthodes différentes | char const & operator[](int i) const; | char & operator[](int i); | mais lui passe par une classe intermédiaire. | | C'est juste parce qu'il parle d'une époque où il n'y | avait pas de const, ou il y a une faille dans mon | approche que je ne vois pas ?
Une faille (classique) dans ton raisonnement.
Supposons
struct A { const char& operator[](int) const; char& operator[](int); };
A a;
char c = a[4];
Pour déterminer quelle operator[] appeler, il faut faire une résolution de surcharge. Pour des raisons de commodité d'écriture, on va réecire les fonctions comme
la fonction #1 réalise un best macth, alors que pour appeler #2 il faut faire une cv-qualification conversion pour l'argument "&a". Une telle transformation est toujours moins bien que la transformation identité, donc la résolution de surcharge prochame la fonction #1 lauréate du tournoi.
-- Gaby
Benoit Dejean
Le Fri, 03 Oct 2003 08:46:13 +0000, amerio a écrit :
Il y a une faille. Mettre un accesseur en const garantit juste que cette accesseur sera appéle si l'objet est const. Mais sur un objet non-const, même pour un accés en lecture, c'est l'accesseur non-const qui sera appelé. D'ou l'idée répandu de passé par un "proxy", cad une classe intermédiaire.
oui, mais pour reprendre le bout de code en question, je ne pense pas qu'on puisse aller bien loin, étant donné, que si l'objet est const
class char_ref { friend class String; int i; String *s; char_ref(String *ss, int ii) { s=ss, i=ii; } public: void operator=(char c); operator char(); };
class String { friend class char_ref; char *r; public: char_ref operator[](int i) { return char_ref(this, i); } };
int main() { String s1, s2;
s1[0]=s2[0];
const String &s3(s2);
s1[0]=s3[0]; // aïe }
bref, avec le bout de code en question, on a le problème que tu évoques. personnellement, si la sémantique diffère entre la lecture et l'écriture, plutôt que de faire 2 versions, je ferais un getter/setter
Le Fri, 03 Oct 2003 08:46:13 +0000, amerio a écrit :
Il y a une faille.
Mettre un accesseur en const garantit juste que cette accesseur sera
appéle si l'objet est const.
Mais sur un objet non-const, même pour un accés en lecture, c'est
l'accesseur non-const qui sera appelé.
D'ou l'idée répandu de passé par un "proxy", cad une classe
intermédiaire.
oui, mais pour reprendre le bout de code en question, je ne pense pas
qu'on puisse aller bien loin, étant donné, que si l'objet est const
class char_ref
{
friend class String;
int i;
String *s;
char_ref(String *ss, int ii) { s=ss, i=ii; }
public:
void operator=(char c);
operator char();
};
class String
{
friend class char_ref;
char *r;
public:
char_ref operator[](int i)
{ return char_ref(this, i); }
};
int main()
{
String s1, s2;
s1[0]=s2[0];
const String &s3(s2);
s1[0]=s3[0]; // aïe
}
bref, avec le bout de code en question, on a le problème que tu évoques.
personnellement, si la sémantique diffère entre la lecture et
l'écriture, plutôt que de faire 2 versions, je ferais un getter/setter
Le Fri, 03 Oct 2003 08:46:13 +0000, amerio a écrit :
Il y a une faille. Mettre un accesseur en const garantit juste que cette accesseur sera appéle si l'objet est const. Mais sur un objet non-const, même pour un accés en lecture, c'est l'accesseur non-const qui sera appelé. D'ou l'idée répandu de passé par un "proxy", cad une classe intermédiaire.
oui, mais pour reprendre le bout de code en question, je ne pense pas qu'on puisse aller bien loin, étant donné, que si l'objet est const
class char_ref { friend class String; int i; String *s; char_ref(String *ss, int ii) { s=ss, i=ii; } public: void operator=(char c); operator char(); };
class String { friend class char_ref; char *r; public: char_ref operator[](int i) { return char_ref(this, i); } };
int main() { String s1, s2;
s1[0]=s2[0];
const String &s3(s2);
s1[0]=s3[0]; // aïe }
bref, avec le bout de code en question, on a le problème que tu évoques. personnellement, si la sémantique diffère entre la lecture et l'écriture, plutôt que de faire 2 versions, je ferais un getter/setter
Marc Boyer
Gabriel Dos Reis wrote:
Marc Boyer writes: | Je suis en train de lire le "Design & Evolution of C++",
interessant ouvrage, n'est-ec pas ? :-)
Oui, j'ai réussi à le faire commander. Et c'est en effet vraiment très intéressant.
Une faille (classique) dans ton raisonnement.
Je n'ai pas la prétension d'être très original ;-)
la fonction #1 réalise un best macth, alors que pour appeler #2 il faut faire une cv-qualification conversion pour l'argument "&a". Une telle transformation est toujours moins bien que la transformation identité, donc la résolution de surcharge prochame la fonction #1 lauréate du tournoi.
OK, merci. Au fait, puisque je te coince dans ce fil, t'aurais pas TC++PL v1 ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Gabriel Dos Reis wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| Je suis en train de lire le "Design & Evolution of C++",
interessant ouvrage, n'est-ec pas ? :-)
Oui, j'ai réussi à le faire commander.
Et c'est en effet vraiment très intéressant.
Une faille (classique) dans ton raisonnement.
Je n'ai pas la prétension d'être très original ;-)
la fonction #1 réalise un best macth, alors que pour appeler #2 il faut
faire une cv-qualification conversion pour l'argument "&a".
Une telle transformation est toujours moins bien que la transformation
identité, donc la résolution de surcharge prochame la fonction #1
lauréate du tournoi.
OK, merci.
Au fait, puisque je te coince dans ce fil, t'aurais pas TC++PL v1 ?
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Marc Boyer writes: | Je suis en train de lire le "Design & Evolution of C++",
interessant ouvrage, n'est-ec pas ? :-)
Oui, j'ai réussi à le faire commander. Et c'est en effet vraiment très intéressant.
Une faille (classique) dans ton raisonnement.
Je n'ai pas la prétension d'être très original ;-)
la fonction #1 réalise un best macth, alors que pour appeler #2 il faut faire une cv-qualification conversion pour l'argument "&a". Une telle transformation est toujours moins bien que la transformation identité, donc la résolution de surcharge prochame la fonction #1 lauréate du tournoi.
OK, merci. Au fait, puisque je te coince dans ce fil, t'aurais pas TC++PL v1 ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Gabriel Dos Reis
Marc Boyer writes:
| Au fait, puisque je te coince dans ce fil, t'aurais pas TC++PL v1 ?
Je ne l'ai pas acheté, mais elle est disponible dans la bibliothèque de mon ancienne école. Tu pourrais peut-être voir ça avec Samy.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| Au fait, puisque je te coince dans ce fil, t'aurais pas TC++PL v1 ?
Je ne l'ai pas acheté, mais elle est disponible dans la bibliothèque
de mon ancienne école. Tu pourrais peut-être voir ça avec Samy.
| Au fait, puisque je te coince dans ce fil, t'aurais pas TC++PL v1 ?
Je ne l'ai pas acheté, mais elle est disponible dans la bibliothèque de mon ancienne école. Tu pourrais peut-être voir ça avec Samy.
-- Gaby
Samuel Krempp
le Friday 03 October 2003 11:11, écrivit :
Le Fri, 03 Oct 2003 08:46:13 +0000, amerio a écrit :
Il y a une faille. Mettre un accesseur en const garantit juste que cette accesseur sera appéle si l'objet est const. Mais sur un objet non-const, même pour un accés en lecture, c'est l'accesseur non-const qui sera appelé. D'ou l'idée répandu de passé par un "proxy", cad une classe intermédiaire.
oui, mais pour reprendre le bout de code en question, je ne pense pas qu'on puisse aller bien loin, étant donné, que si l'objet est const [..]
pour aller plus loin il faut définir un operator[] const, qui renvoit un const_char_ref. Un proxy de ce genre pour faire une string copy-on-write est le thème d'un des chapitres d'Effective C++ il me semble. Je crois qu'actuellement il y a plutôt consensus pour des strings qui copient tt le temps, il semble que (même sans threads) le COW n'est rentable que lorsque le tableau sous jacent est vraiment grand, et n'est pas rentable en moyenne pour les string rencontrées dans la nature. Pour une classe d'images ou autres très gros objets ça pourrait être rentable, mais personnellement j'utilise mes images comme des shared pointers, en appelant explicitement une fonction qui obtient une instance non partagée de l'objet avant de le modifier. ça laisse un risque de modifier par inadvertance une image partagée si on oublie d'appeler cette fonction, mais sinon ça rend bien visible dans le code les moments où il y a risque de copie d'image, et c'est un point nécessaire qd ces copies sont grosses au point de devoir être contrôlées.
enfin bref, on peut qd même "aller loin" en direction du copy-on-write avec cette technique, mais ce n'est pas forcément utile aussi souvent qu'on pourrait naïvement le penser.
-- Sam
le Friday 03 October 2003 11:11, bnet@ifrance.com écrivit :
Le Fri, 03 Oct 2003 08:46:13 +0000, amerio a écrit :
Il y a une faille.
Mettre un accesseur en const garantit juste que cette accesseur sera
appéle si l'objet est const.
Mais sur un objet non-const, même pour un accés en lecture, c'est
l'accesseur non-const qui sera appelé.
D'ou l'idée répandu de passé par un "proxy", cad une classe
intermédiaire.
oui, mais pour reprendre le bout de code en question, je ne pense pas
qu'on puisse aller bien loin, étant donné, que si l'objet est const
[..]
pour aller plus loin il faut définir un operator[] const, qui renvoit un
const_char_ref. Un proxy de ce genre pour faire une string copy-on-write
est le thème d'un des chapitres d'Effective C++ il me semble.
Je crois qu'actuellement il y a plutôt consensus pour des strings qui
copient tt le temps, il semble que (même sans threads) le COW n'est
rentable que lorsque le tableau sous jacent est vraiment grand, et n'est
pas rentable en moyenne pour les string rencontrées dans la nature.
Pour une classe d'images ou autres très gros objets ça pourrait être
rentable, mais personnellement j'utilise mes images comme des shared
pointers, en appelant explicitement une fonction qui obtient une instance
non partagée de l'objet avant de le modifier. ça laisse un risque de
modifier par inadvertance une image partagée si on oublie d'appeler cette
fonction, mais sinon ça rend bien visible dans le code les moments où il y
a risque de copie d'image, et c'est un point nécessaire qd ces copies sont
grosses au point de devoir être contrôlées.
enfin bref, on peut qd même "aller loin" en direction du copy-on-write avec
cette technique, mais ce n'est pas forcément utile aussi souvent qu'on
pourrait naïvement le penser.
Le Fri, 03 Oct 2003 08:46:13 +0000, amerio a écrit :
Il y a une faille. Mettre un accesseur en const garantit juste que cette accesseur sera appéle si l'objet est const. Mais sur un objet non-const, même pour un accés en lecture, c'est l'accesseur non-const qui sera appelé. D'ou l'idée répandu de passé par un "proxy", cad une classe intermédiaire.
oui, mais pour reprendre le bout de code en question, je ne pense pas qu'on puisse aller bien loin, étant donné, que si l'objet est const [..]
pour aller plus loin il faut définir un operator[] const, qui renvoit un const_char_ref. Un proxy de ce genre pour faire une string copy-on-write est le thème d'un des chapitres d'Effective C++ il me semble. Je crois qu'actuellement il y a plutôt consensus pour des strings qui copient tt le temps, il semble que (même sans threads) le COW n'est rentable que lorsque le tableau sous jacent est vraiment grand, et n'est pas rentable en moyenne pour les string rencontrées dans la nature. Pour une classe d'images ou autres très gros objets ça pourrait être rentable, mais personnellement j'utilise mes images comme des shared pointers, en appelant explicitement une fonction qui obtient une instance non partagée de l'objet avant de le modifier. ça laisse un risque de modifier par inadvertance une image partagée si on oublie d'appeler cette fonction, mais sinon ça rend bien visible dans le code les moments où il y a risque de copie d'image, et c'est un point nécessaire qd ces copies sont grosses au point de devoir être contrôlées.
enfin bref, on peut qd même "aller loin" en direction du copy-on-write avec cette technique, mais ce n'est pas forcément utile aussi souvent qu'on pourrait naïvement le penser.
-- Sam
Samuel Krempp
le Friday 03 October 2003 11:19, écrivit :
Marc Boyer writes:
| Au fait, puisque je te coince dans ce fil, t'aurais pas TC++PL v1 ?
Je ne l'ai pas acheté, mais elle est disponible dans la bibliothèque de mon ancienne école. Tu pourrais peut-être voir ça avec Samy.
ah ben sit u dis que ça y est, je veux bien faire les 100m de trajet à l'occasion pour rendre service. mais de tte façon la bibli est en travaux jusqu'à la semaine prochaine.
-- Sam(y)
le Friday 03 October 2003 11:19, dosreis@cmla.ens-cachan.fr écrivit :
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| Au fait, puisque je te coince dans ce fil, t'aurais pas TC++PL v1 ?
Je ne l'ai pas acheté, mais elle est disponible dans la bibliothèque
de mon ancienne école. Tu pourrais peut-être voir ça avec Samy.
ah ben sit u dis que ça y est, je veux bien faire les 100m de trajet à
l'occasion pour rendre service.
mais de tte façon la bibli est en travaux jusqu'à la semaine prochaine.
| Au fait, puisque je te coince dans ce fil, t'aurais pas TC++PL v1 ?
Je ne l'ai pas acheté, mais elle est disponible dans la bibliothèque de mon ancienne école. Tu pourrais peut-être voir ça avec Samy.
ah ben sit u dis que ça y est, je veux bien faire les 100m de trajet à l'occasion pour rendre service. mais de tte façon la bibli est en travaux jusqu'à la semaine prochaine.
-- Sam(y)
Marc Boyer
In article <3f7d6811$0$20645$, Samuel Krempp wrote:
le Friday 03 October 2003 11:19, écrivit :
Marc Boyer writes: | Au fait, puisque je te coince dans ce fil, t'aurais pas TC++PL v1 ?
Je ne l'ai pas acheté, mais elle est disponible dans la bibliothèque de mon ancienne école. Tu pourrais peut-être voir ça avec Samy.
ah ben sit u dis que ça y est, je veux bien faire les 100m de trajet à l'occasion pour rendre service. mais de tte façon la bibli est en travaux jusqu'à la semaine prochaine.
Ca peut tout à fait attendre une semaine, mais ça me rendrait en effet *vraiment* service.
Merci
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
In article <3f7d6811$0$20645$626a54ce@news.free.fr>, Samuel Krempp wrote:
le Friday 03 October 2003 11:19, dosreis@cmla.ens-cachan.fr écrivit :
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| Au fait, puisque je te coince dans ce fil, t'aurais pas TC++PL v1 ?
Je ne l'ai pas acheté, mais elle est disponible dans la bibliothèque
de mon ancienne école. Tu pourrais peut-être voir ça avec Samy.
ah ben sit u dis que ça y est, je veux bien faire les 100m de trajet à
l'occasion pour rendre service.
mais de tte façon la bibli est en travaux jusqu'à la semaine prochaine.
Ca peut tout à fait attendre une semaine, mais ça me rendrait
en effet *vraiment* service.
Merci
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
In article <3f7d6811$0$20645$, Samuel Krempp wrote:
le Friday 03 October 2003 11:19, écrivit :
Marc Boyer writes: | Au fait, puisque je te coince dans ce fil, t'aurais pas TC++PL v1 ?
Je ne l'ai pas acheté, mais elle est disponible dans la bibliothèque de mon ancienne école. Tu pourrais peut-être voir ça avec Samy.
ah ben sit u dis que ça y est, je veux bien faire les 100m de trajet à l'occasion pour rendre service. mais de tte façon la bibli est en travaux jusqu'à la semaine prochaine.
Ca peut tout à fait attendre une semaine, mais ça me rendrait en effet *vraiment* service.
Merci
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
kanze
Samuel Krempp wrote in message news:<3f7d545f$0$10408$...
le Friday 03 October 2003 11:11, écrivit :
Il y a une faille. Mettre un accesseur en const garantit juste que cette accesseur sera appéle si l'objet est const. Mais sur un objet non-const, même pour un accés en lecture, c'est l'accesseur non-const qui sera appelé. D'ou l'idée répandu de passé par un "proxy", cad une classe intermédiaire.
oui, mais pour reprendre le bout de code en question, je ne pense pas qu'on puisse aller bien loin, étant donné, que si l'objet est const
pour aller plus loin il faut définir un operator[] const, qui renvoit un const_char_ref. Un proxy de ce genre pour faire une string copy-on-write est le thème d'un des chapitres d'Effective C++ il me semble. Je crois qu'actuellement il y a plutôt consensus pour des strings qui copient tt le temps, il semble que (même sans threads) le COW n'est rentable que lorsque le tableau sous jacent est vraiment grand, et n'est pas rentable en moyenne pour les string rencontrées dans la nature.
Ça dépend des utilisations. Ça dépend aussi de l'interface ; il y a bien un consensus que l'interface de std::string fait tout pour pénaliser le COW. En revanche, il y a au moins une personne dans clc++m qui a rapporté une amélioration notable avec COW, et dans un milieu multi-thread en plus. (Mais d'après ce que j'ai compris, il ne supporte pas toute l'interface de std::string.)
Pour une classe d'images ou autres très gros objets ça pourrait être rentable, mais personnellement j'utilise mes images comme des shared pointers, en appelant explicitement une fonction qui obtient une instance non partagée de l'objet avant de le modifier. ça laisse un risque de modifier par inadvertance une image partagée si on oublie d'appeler cette fonction, mais sinon ça rend bien visible dans le code les moments où il y a risque de copie d'image, et c'est un point nécessaire qd ces copies sont grosses au point de devoir être contrôlées.
enfin bref, on peut qd même "aller loin" en direction du copy-on-write avec cette technique, mais ce n'est pas forcément utile aussi souvent qu'on pourrait naïvement le penser.
Il ne sert pas que pour COW. Il est très utile, par exemple, pour des éléments d'un tableau super-grand, qui ne se tient même pas en memoire.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> wrote in message
news:<3f7d545f$0$10408$626a54ce@news.free.fr>...
le Friday 03 October 2003 11:11, bnet@ifrance.com écrivit :
Il y a une faille.
Mettre un accesseur en const garantit juste que cette accesseur
sera appéle si l'objet est const. Mais sur un objet non-const,
même pour un accés en lecture, c'est l'accesseur non-const qui sera
appelé. D'ou l'idée répandu de passé par un "proxy", cad une
classe intermédiaire.
oui, mais pour reprendre le bout de code en question, je ne pense
pas qu'on puisse aller bien loin, étant donné, que si l'objet est
const
pour aller plus loin il faut définir un operator[] const, qui renvoit
un const_char_ref. Un proxy de ce genre pour faire une string
copy-on-write est le thème d'un des chapitres d'Effective C++ il me
semble. Je crois qu'actuellement il y a plutôt consensus pour des
strings qui copient tt le temps, il semble que (même sans threads) le
COW n'est rentable que lorsque le tableau sous jacent est vraiment
grand, et n'est pas rentable en moyenne pour les string rencontrées
dans la nature.
Ça dépend des utilisations. Ça dépend aussi de l'interface ; il y a bien
un consensus que l'interface de std::string fait tout pour pénaliser le
COW. En revanche, il y a au moins une personne dans clc++m qui a
rapporté une amélioration notable avec COW, et dans un milieu
multi-thread en plus. (Mais d'après ce que j'ai compris, il ne supporte
pas toute l'interface de std::string.)
Pour une classe d'images ou autres très gros objets ça pourrait être
rentable, mais personnellement j'utilise mes images comme des shared
pointers, en appelant explicitement une fonction qui obtient une
instance non partagée de l'objet avant de le modifier. ça laisse un
risque de modifier par inadvertance une image partagée si on oublie
d'appeler cette fonction, mais sinon ça rend bien visible dans le code
les moments où il y a risque de copie d'image, et c'est un point
nécessaire qd ces copies sont grosses au point de devoir être
contrôlées.
enfin bref, on peut qd même "aller loin" en direction du copy-on-write
avec cette technique, mais ce n'est pas forcément utile aussi souvent
qu'on pourrait naïvement le penser.
Il ne sert pas que pour COW. Il est très utile, par exemple, pour des
éléments d'un tableau super-grand, qui ne se tient même pas en
memoire.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Samuel Krempp wrote in message news:<3f7d545f$0$10408$...
le Friday 03 October 2003 11:11, écrivit :
Il y a une faille. Mettre un accesseur en const garantit juste que cette accesseur sera appéle si l'objet est const. Mais sur un objet non-const, même pour un accés en lecture, c'est l'accesseur non-const qui sera appelé. D'ou l'idée répandu de passé par un "proxy", cad une classe intermédiaire.
oui, mais pour reprendre le bout de code en question, je ne pense pas qu'on puisse aller bien loin, étant donné, que si l'objet est const
pour aller plus loin il faut définir un operator[] const, qui renvoit un const_char_ref. Un proxy de ce genre pour faire une string copy-on-write est le thème d'un des chapitres d'Effective C++ il me semble. Je crois qu'actuellement il y a plutôt consensus pour des strings qui copient tt le temps, il semble que (même sans threads) le COW n'est rentable que lorsque le tableau sous jacent est vraiment grand, et n'est pas rentable en moyenne pour les string rencontrées dans la nature.
Ça dépend des utilisations. Ça dépend aussi de l'interface ; il y a bien un consensus que l'interface de std::string fait tout pour pénaliser le COW. En revanche, il y a au moins une personne dans clc++m qui a rapporté une amélioration notable avec COW, et dans un milieu multi-thread en plus. (Mais d'après ce que j'ai compris, il ne supporte pas toute l'interface de std::string.)
Pour une classe d'images ou autres très gros objets ça pourrait être rentable, mais personnellement j'utilise mes images comme des shared pointers, en appelant explicitement une fonction qui obtient une instance non partagée de l'objet avant de le modifier. ça laisse un risque de modifier par inadvertance une image partagée si on oublie d'appeler cette fonction, mais sinon ça rend bien visible dans le code les moments où il y a risque de copie d'image, et c'est un point nécessaire qd ces copies sont grosses au point de devoir être contrôlées.
enfin bref, on peut qd même "aller loin" en direction du copy-on-write avec cette technique, mais ce n'est pas forcément utile aussi souvent qu'on pourrait naïvement le penser.
Il ne sert pas que pour COW. Il est très utile, par exemple, pour des éléments d'un tableau super-grand, qui ne se tient même pas en memoire.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
