OVH Cloud OVH Cloud

Acces en lecture seule sur un membre

8 réponses
Avatar
Marc Boyer
Je suis peut-être encore en train de réinventer la roue,
mais quid d'offrir une référence constante sur un membre privé
pour laisser un accès en lecture ?

class Foo{
std::vector<int> values;
public:
const std::vector<int>& cvalues;
Foo():cvalues(values){ }
};

Car autant il me semble fréquent de restreindre les accès en
écriture, autant pour des lectures sans modifs ?

Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain

8 réponses

Avatar
Marc Boyer
Le 13-02-2006, Ploc a écrit :
Marc Boyer wrote:
Je suis peut-être encore en train de réinventer la roue,
mais quid d'offrir une référence constante sur un membre privé
pour laisser un accès en lecture ?

class Foo{
std::vector<int> values;
public:
const std::vector<int>& cvalues;
Foo():cvalues(values){ }
};

Car autant il me semble fréquent de restreindre les accès en
écriture, autant pour des lectures sans modifs ?


Foo{
const std::vector<int>& get_values() {return values;}
}


Oui, en effet. Avec un get devant, ça fait tout de
suite moins nouveaux.

Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain


Avatar
Marc Boyer
Le 13-02-2006, Ploc a écrit :
Ploc wrote:
Foo{
const std::vector<int>& get_values() {return values;}
}
non?



Il faut aussi que le client recupere l'adresse avec un const &


Oui.

sinon il recupere une copie qui ne suivra pas les evolutions de values.


En effet.

Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain


Avatar
Ploc
Marc Boyer wrote:
Je suis peut-être encore en train de réinventer la roue,
mais quid d'offrir une référence constante sur un membre privé
pour laisser un accès en lecture ?

class Foo{
std::vector<int> values;
public:
const std::vector<int>& cvalues;
Foo():cvalues(values){ }
};

Car autant il me semble fréquent de restreindre les accès en
écriture, autant pour des lectures sans modifs ?

Marc Boyer



Foo{
const std::vector<int>& get_values() {return values;}
}
non?

Avatar
Ploc
Ploc wrote:
Foo{
const std::vector<int>& get_values() {return values;}
}
non?



Il faut aussi que le client recupere l'adresse avec un const &
sinon il recupere une copie qui ne suivra pas les evolutions de values.

Je l'ai compris comme ca. Merci de me dire si je me trompe.

Avatar
Falk Tannhäuser
Marc Boyer wrote:
Foo{
const std::vector<int>& get_values() {return values;}
}
Oui, en effet. Avec un get devant, ça fait tout de

suite moins nouveaux.


... et avec un 'const' en plus
std::vector<int> const& get_values() const { return values; }
ça fait carrément classique !

Falk


Avatar
Marc Boyer
Le 13-02-2006, Falk Tannhäuser a écrit :
Marc Boyer wrote:
Foo{
const std::vector<int>& get_values() {return values;}
}
Oui, en effet. Avec un get devant, ça fait tout de

suite moins nouveaux.


... et avec un 'const' en plus
std::vector<int> const& get_values() const { return values; }
ça fait carrément classique !


Voui...
Je ne code pas assez souvent en C++. Là, j'ai l'occasion d'en
faire, et c'est bizarre de se trouver face à cette grosse
boite à outils, dont on connait le maniement d'un bon nombre,
mais on se demande comment les combiner...

Bon, allez, je vais pas vous raconter ma vie de faut-débutant
en C++.

Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain



Avatar
kanze
Marc Boyer wrote:

Je suis peut-être encore en train de réinventer la roue, mais
quid d'offrir une référence constante sur un membre privé pour
laisser un accès en lecture ?

class Foo{
std::vector<int> values;
public:
const std::vector<int>& cvalues;
Foo():cvalues(values){ }
};

Car autant il me semble fréquent de restreindre les accès en
écriture, autant pour des lectures sans modifs ?


Ça ne restreint pas seulement les accès en écriture. Ça empèche
aussi la génération automatique de l'affectation (et n'oublie
pas non plus de fournir un constructeur de copie, parce que je
ne crois pas que tu seras content avec celui que génère le
compilateur par défaut).

--
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

Avatar
Marc Boyer
Le 13-02-2006, kanze a écrit :
Marc Boyer wrote:

Je suis peut-être encore en train de réinventer la roue, mais
quid d'offrir une référence constante sur un membre privé pour
laisser un accès en lecture ?

class Foo{
std::vector<int> values;
public:
const std::vector<int>& cvalues;
Foo():cvalues(values){ }
};

Car autant il me semble fréquent de restreindre les accès en
écriture, autant pour des lectures sans modifs ?


Ça ne restreint pas seulement les accès en écriture. Ça empèche
aussi la génération automatique de l'affectation (et n'oublie
pas non plus de fournir un constructeur de copie, parce que je
ne crois pas que tu seras content avec celui que génère le
compilateur par défaut).


Voui, les references et la copie. Ca m'avait échappé.
C'est marrant de voir chez soi ce qu'on observe dans le
processus d'apprentissage des élèves: on leur montre comment
il faut faire, il tente de faire autrement pour voir, ils
comprennent pourquoi ça marche pas et pourquoi la solution
bien établie est meilleure.

Merci,
Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain