Fonction membre constante, cas litigieux..

Bonjour à tous,

Je me posais une question qui depuis me hante :lol:.

J'ai appris qu'une fonction membre constante est une fonction qui ne modifie pas ses variables membres. Ceci étant dit, imaginons le cas suivant :

Code:

---

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

class A { public: // ...   void Update () // <--- const ou pas ? { objetB->Update (uneValeur); }   private: int uneValeur;   // Référence constante vers une classe B const B & objetB; };

---

Je me demande si, d'un point de vue logique, il faut mettre const. En effet, d'un côté cette fonction ne modifie pas directement ses variables membres, donc je serai tenté de mettre const, mais d'un autre côté, la fonction update de B VA mettre à jour sa structure interne et donc, d'une certaine manière, également A (puisque A dispose d'un objet B dans sa structure).

Voilà ^^

Citation:

---

Envoyé par Bakura

Bonjour à tous,

Je me posais une question qui depuis me hante :lol:.

J'ai appris qu'une fonction membre constante est une fonction qui ne modifie pas ses variables membres. Ceci étant dit, imaginons le cas suivant :

Code:

---

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

class A { public: // ...   void Update () // <--- const ou pas ? { objetB->Update (uneValeur); }   private: int uneValeur;   // Référence constante vers une classe B const B & objetB; };

---

Je me demande si, d'un point de vue logique, il faut mettre const. En effet, d'un côté cette fonction ne modifie pas directement ses variables membres, donc je serai tenté de mettre const, mais d'un autre côté, la fonction update de B VA mettre à jour sa structure interne et donc, d'une certaine manière, également A (puisque A dispose d'un objet B dans sa structure).

Voilà ^^

---

Tu dois effacer le const sûr objetB, parce que ce const met le vrai objet en const...

Bien vu ;). Mais ça ne répond pas sur le premirer const :).

Salut,

Sans être vraiment tout à fait sur de moi, je pense que la méthode update de la classe A devrait être const.

En effet, l'objectif d'une méthode const est bien de définir quelles méthodes peuvent être appelées sur les objets const.

Du point de vue de la classe A, un appel à la méthode update modifie effectivement le "contenu" de l'objet de type B mais la référence sur l'objet B inclut dans la classe A ne change pas.

La classe A ne "voit" pas les changements inhérents (d'une certaine manière ça ne la regarde pas) à l'appel d'update car elle ne voit que sa référence constante sur B.

Je vais suivre cette discussion, question intéressante !
Agamitsudo.

C'est effectivement comme ça que je vois les choses aussi... Mais... J'arrête pas de me dire que l'objet B fait quand même parti de la classe A :aie:.

Avant tout, il faut regarder ce que signifie une "fonction membre constante". Cela veut dire que l'objet réagira identiquement avant et après l'appel de la fonction const à une même requette, ca ne veut pas dire que l'intérieur de l'objet est le même. C'est son état "sémantique" qui n'a pas bougé, pas son état "syntaxique"

Imagine le code suivant

Code:

---

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

class Complex { double a,b; // (a;b) représente soit Re/Im soit Module+ argument Methode* methode;   public: Complex(double aa,double bb,Methode* mm=Carthe):a(aa),b(bb),m(mm){} double Re() const {return methode->Re(a,b);} double Im() const {return methode->Im(a,b);}   void Update(Methode* m){ double x=a,y=b; methode=m; a=methode->membre1(x,y); b=methode->membre2(x,y)} };   int foo() { Complex c(2,2); //c représente 2+2i c.Update(Exp); //a et b ont changé de valeur, pourtant le c va réagir de la même manière avant et après l'appel. Pourtant l'état interne de l'objet a été modifié }

---

Note: Si le code ne te semble pas clair (c'est possible :aie:), je détaillerai.
Note2: le code est moche, pas sécurisé, c'est juste pour l'idée. Si quelqu'un a un meilleur exemple, je suis preneur.

Dans ce contexte, est ce que Update devrait être constante ? Oui, la valeur du complexe ne change pas, c'est juste sa représentation qui est modifiée. Donc il faut déclarer Update const. Problème on change a et b, ce qui est en désaccord avec la notion de fonction membre constante du C++.

Dans ce cas, il faut les déclarer mutable pour qu'ils puissent être modifiés par Update car ils ne sont que des données internes à Complex. Personne à part elle ne les connait.

Dans ton cas, ce qu'il faut se poser comme question, c'est:
Est ce que si j'appelle Update sur objetB, l'objet qui le contient va réagir différement. Si oui, pas const, sinon const et modification(s) interne(s) pour adapater.

Le mot clef const n'est pas là pour embêter les gens mais pour dire à la personne qui utilise la classe qu'on lui dit qu'il peut sans craindre faire 2 appels successifs à la méthode et toujours espérer avoir le même résultat.

Sinon, tu peux même écrire:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

#include <iostream>   using namespace std;   class B { public: int valeur; void Update( int x ) { valeur = x; } };   class A { public: // ...   A( B& b ) : objetB( b ) , uneValeur(0) {}   void Do() { }   void Update () const { B& /*const*/ b = objetB; // pas de const mais compile b.Update (++b.valeur); // tant qu'on y est !   int& val = const_cast< int& > ( uneValeur ); // cast explicit nécessaire ++val; // toujours ok ! }   B & objetB; int uneValeur; };     int main() { B b; const A a(b); // c'est un objet const, j'vous jure ! a.Update(); cout << a.objetB.valeur << endl; // renvoi 1 cout << a.uneValeur << endl; // renvoi 1 a.Update(); cout << a.objetB.valeur << endl; // renvoi 2 ! cout << a.uneValeur << endl; // renvoi 2 ! return 0; }

---

Mais quel serait l'intérêt ?
à force, le code sera complètement illisible et pas propre du tout, le mot clef const perd absolument tout son intérêt.

Donc pour répondre à ta question, oui, une méthode qui modifie effectivement ses membres, qu'ils soient référencés ou pas, ne doit pas être const, pensez un peu à ceux qui vont reprendre votre code ! :aie:

Citation:

---

Est ce que si j'appelle Update sur objetB, l'objet qui le contient va réagir différement. Si oui, pas const, sinon const et modification(s) interne(s) pour adapater.

---

Non, l'objet réagira toujours de la même façon.

En fait la fonction Update va mettre un jour une variable uniform dans un shader. Un truc du genre glUniform (uneValeur). Donc selon toi, je dois mettre const.

Et selon Julien, pas const :aie:.

Puisque je parle de glUniform... Il y a un autre cas qui me pose problème également... J'avoue être assez perdu. En l'occurence, la classe B ressemble à ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class B { public: void Update (type uneValeur) { glUniform (id, uneValeur); }   private: GLuint id; // Identifiant de la variable dans le shader }

---

Même problème, en fait... Update ne modifie rien dans la classe. Tant qu'on appelle la fonction Update avec la même valeur en paramètre, ça ne changera rien. On aura beau l'appeler 100 fois ça fera la même chose. Mais, d'un côté, ça modifie quand même des choses.

Grrr... La fonction membre constante est devenue aujourd'hui très confuse dans ma tête =).

Citation:

---

Même problème, en fait... Update ne modifie rien dans la classe. Tant qu'on appelle la fonction Update avec la même valeur en paramètre, ça ne changera rien. On aura beau l'appeler 100 fois ça fera la même chose

---

Oui, tant que c'est la même valeur. Mais si tu change de valeur, ton objet change, donc c'est pas const.

Salut,

Ceci dit, ce n'est même pas en tant que référence (non constante) que tu dois déclarer objetB, mais carrément sous la forme d'une référence mutable...

En effet, le fait de déclarer une fonction constante fait que tous les membres de la classe seront considérés comme constants...

Le corollaire de ce fait est que... tu ne pourra appeler que des fonctions membres déclarées constantes des membres :aie:

Bien sur, tu peux t'amuser avec le const_cast, sous la forme de

Code:

---

1 2 3 4 5 6 7 8 9

void A::update() const { /* Si B::update() n'est pas une fonction membre constante   */ const_cast<B &>(objetB).update(value); /* OK */ objetB.update(value); /* NOK: appel d'une fonction non constante   * sur un objet constant   */ }

---

mais, en l'occurrence objetB agit plutôt comme un buffer, et il reste donc tout à fait logique d'en permettre la modification même si nous travaillons avec un objet constant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

class A { public: void update() const { objetB.update(value); /* OK objetB reste non constant   * car déclaré mutable   */ } private: mutable B& objetB; };

---

Au fait, car personne n'a réagi à cette horreur...
dans le code que tu présente, tu essaye d'accéder au membre d'une référence avec la fleche ->...

Rassure moi, c'est juste une erreur de copie :question:

Davidbrcz a bien résumé la chose. Const, c'est une histoire de sémantique de ton objet, et d'engagement vis à vis de l'appelant.

si tu es capable de garantir que tout appel à ton objet, avant le update et après le update, donneront le même résultat, alors il faut donner cette indication à ton client en déclarant ta méthode const.

Si tu n'es pas capable de donner cette garantie (ou si tu es sûr que ce n'est pas le cas), tu ne dois pas mettre const.

Au-delà de ça, conceptuellement, j'ai un peu de mal avec l'idée d'une méthode update qui soit const... Et plus généralement, de l'utilité d'une méthode const sans valeur de retour (au sens étendu, incluant les paramètres out et inout).

D'accord. Merci à tous pour vos réponses. Je vire donc le const, en effet après avoir lu vos réponses c'est ce qui paraît le plus logique.

koala> Oui oui bien sûr c'est une erreur de frappe (j'avais écrit ce code directement sur le forum...) pour le ->.

Je mettrai le bout de code complet une fois que je l'aurai fait, comme ça vous saurez exactement ce que je voulais faire =).

une fonction update qui est const c'est une fonction mal nommée...