modifier un attribut avec une fonction const?

Bonjour,
voici mon .h et mon .cpp :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class ClasseA: public ClasseB{ public: explicit ClasseA(); void maFonction(int i) const override; private: std::set <int> maliste; };

---

Code:

---

1 2 3 4 5

ClasseA::ClasseA(): ClasseB() { } void ClasseA::maFonction(int i)const { maliste.insert(i); }

---

J'ai une question assez simple : Est ce que ma fonction maFonction(int i) pourra ajouter des valeurs dans maliste sachant que cette fonction est declarée const et que je ne peux pas changer ça vu que je l'override?
Et y a t il un moyen pour y parvenir?

Merci à vous

Salut,

Le mot clé const indique explicitement que la fonction n'est pas sensée modifier l'état de ta classe.

Tu ne peux donc pas -- a priori -- envisager de modifier les données membres de ta classes avec cette fonction.

Cependant, tu peux considérer qu'une des données représente d'avantage des données en cache qu'autre chose, et que le cache devra être mis à jour de manière régulière, malgré le fait cela ne modifie pas l'état interne de la classe.

Soyons clairs: cette possibilité n'est absolument pas adaptable à toutes les situations!!! En fonction de ce qu'est ClasseA, du service rendu par maFonction et de l'utilité à laquelle tu destines maListe, la possibilité que maliste puisse -- effectivement -- être considérée comme une donnée de cache est particulièrement faible!

Mais si tel est effectivement le cas, il "suffit" de déclarer maliste comme étant mutable:

Le code, tel que tu le présentes sera carrément refusé par le compilateur sous prétexte que "l'insertion d'un élément dans set va à l'encontre du (cv) qualifier", mais si tu déclares maliste, voir, parce que la seule version de insert qu'il trouve dans la classe set est une version non constante, alors qu'il ne peut utiliser que des fonctions constantes à l'intérieur d'une fonction membre constante.

Mais si tu déclares maliste, il acceptera de faire appel à la version non constante de insert ;)

Je vais me répéter, mais, je tiens à ce que les choses soient bien claires : cette possibilité t'offre l'occasion de mettre à bat tout le système de contrôle de la const correctness. Si tu en as absolument besoin, fais le. Mais l'idéal -- comme pour tant de choses que le langage autorise mais qui ne sont en définitive que que fausses bonnes idées dans la plupart des cas -- reste malgré tout de s'en passer si l'on peut faire autrement ;)

Merci Koala pour ta réponse très précise.
Effectivement j avais depuis longtemps pris l habitude d éviter «*mutable*»
J en étais venu à penser qu il ne fallait pas l utiliser.
Mais parfois effectivement il faut s en servir
Merci pour ce rappel et ces éclairages
Merci beaucoup

Bonjour,

Je pressens une mauvaise utilisation de mutable.
Que représentent ClasseA, ClasseB et maFonction ?
Pourquoi ClasseB::maFonction est-elle const ?

En tout cas, on peut contourner la constness de ClasseB::maFonction ainsi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

class ClasseB { public: virtual ~ClasseB() {} virtual void maFonction(int i) const = 0; };   class ClasseA final { public: ClasseA() {} void maFonction(int i) { m_set.insert(i); } private: std::set<int> m_set; };   class ClasseARef final : public ClasseB { public: explicit ClasseARef(ClasseA& ref) : ClasseB{}, m_ref{ref} {} void maFonction(int i) const override { m_ref.maFonction(i); } private: ClasseA& m_ref; };

---

Je suis, moi aussi, quasiment certain que tu ne veux pas utiliser mutable dans ta situation, que, soit, tu dois supprimer le cv-qualifier de la fonction, soit tu ne veux purement et simplement pas modifier ta liste à cet endroit.

La possibilité d'utiliser mutable existe, mais, quoi que l'on puisse en dire, il faut rester bien conscient du fait que la const correctness est ta meilleure amie:

C'est la base sur laquelle tu peux t'appuyer pour être en mesure de déterminer si une donnée risque d'être modifiée ou non. Et c'est donc la base sur laquelle tu peux partir de situation claires et précises.

L'utilisation met cette base à mal, en te permettant de modifier une donnée qui n'a -- normalement -- aucune raison de pouvoir l'être. C'est certes pratique, vu que cela permet des choses "impossibles", mais cela implique que tu ne peux plus faire confiance à la constance pour t'assurer que les données ne subissent aucune modification entre deux appels de fonctions. Et ca, c'est loin d'être une situation idéale.

Le fait, est que tu nous as présenté un problème tout à fait général, sans donner la moindre notion du contexte dans lequel tu te trouves effectivement. je me suis donc limité à fournir une solution générale, dont j'ai pris la peine de mettre les dangers en avants.

Mais, si j'avais eu connaissance du contexte réel auquel tu es confronté, j'aurais sans doute pu fournir une alternative bien moins dangereuse et sans doute même bien plus efficace à long terme ;)