Const et priorité de fonction

Bonjour à tous,

J'ai un petit soucis d'ordre technique auquel je ne trouve pas de réponses sur le net.
J'aimerai gérer la priorité des fonctions dans une classe. Ça sera plus simple à expliquer avec l'exemple suivant :

Code:

---

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

#include <iostream>   class Test { private: int a[255] ;   public: inline int& operator[](int index) { printf("No const\n"); return a[index]; } inline const int& operator[](int index) const { printf("Const\n"); return a[index]; } } ;   int main() { Test x ; x[0] = 100 ; printf("%i\n", x[0]) ; printf("%i\n", ((const Test)x)[0]) ;   return 0 ; }

---

Et voici le résulat de l'execution :

Code:

---

1 2 3 4 5 6

$ ./test_priority No const No const 100 Const 100

---

Dans cet exemple, j'ai 2 fonctions pour l'opérateur [], une qui gère en constante, et l'autre sans constante.

Dans le cadre d'un développement d'API, j'aimerai faire en sorte que, par défaut, ce soit la fonction constante qui soient appelé. SAUF quand on s'en sert pour une affectation.
En gros, j'aimerai que x[0]=100 appelle la fonction non constante, et printf("%i\n", x[0]) la fonction constante, sans pour autant devoir caster comme dans le second printf.

Est-ce possible ??
Merci beaucoup. :?

Si tu veux distinguer lecture et écriture, il faut passer par un proxy. Le résultat ne sera toutefois pas parfait.
Un item entier de More Effective C++ y est consacré dans mes souvenirs.

Salut,

Le propre d'un programme est d'être plus complexe que cette "malheureuse" fonction main.

Tu ne manqueras donc surement pas d'occasion de définir des méthodes qui prendront une référence sur un objet de type Test en paramètre, ou qui renverront une telle référence.

C'est à ce point que la constance va apporter toute sa puissance:

Si la fonction que tu définis prend une référence constante, tu ne pourra pas assinger une nouvelle valeur à ton arg[n], alors que tu pourra le faire si la fonction prend une référence non constante.

De la même manière si la fonction que tu écrit renvoie une référence constante, le compilateur se plaindra déjà bien avant l'exécution si tu venais à envisager un code proche de

Code:

---

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

/* si le retour de cette fonction n'était pas constant  * le compilateur se plaindrait de la perte de constance, étant donné  * que arg est une référence constante  */ const Test& foo(const Test& arg) { /*...*/ return arg; } int main() { Test t; /* t n'est pas constant, c'est donc la version non constante   * qui est appelée   */ t[0]=5; /* par contre, le retour de foo est constant...   * le compilateur refuse donc l'écriture de   foo(t)[0] = 5;   /* par contre, il accepte sans problème */ cout<foo(t)[0]; return 0; }

---

La règle pour résoudre la surcharge entre fonction membre const et non const consiste uniquement à regarder si l'objet sur lequel cette fonction est appelée est constant ou pas.

Tu aimerais que cette règle se base sur la façon dont le retour de la fonction va être utilisé, ce qui n'est possible qu'avec le proxy dont parle Luc.

Il me semble qu'un de mes prof m'avait dit que par défaut c'est la méthode non-constante qui est prise, que la version const n'est appelée que pour les objets const et pointeurs d'objets const. Par ailleurs, const sert à vérifier à la compilation qu'une fonction supposée constante ne modifie pas l'objet, mais n'apporte pas de sécurité à l'exécution.

Peut-être que tu peux lever l'ambiguïté comme-ça :

Code:

---

1 2 3

inline int& operator[](int index) { printf("No const\n"); return a[index]; } inline int operator[](int index) const { printf("Const\n"); return a[index]; }

---

Mais bon, à vérifier.

Citation:

---

Envoyé par koala01

Code:

---

cout<foo(t)[0];

---

---

Ca ne devrait pas plutôt être :

Code:

---

cout << foo(t)[0];

---

?

Par curiosité, qu'est-ce-que c'est un proxy (dans ce contexte, je veux dire), un design pattern ?

La question me paraît étrange: vas-tu avoir un comportement différent entre la version const et l'autre? Peux-tu expliciter ton cas, car je n'ai jamais vu d'exemple de ce genre. Sinon, à partir du moment où c'est le même comportement, que t'importe de savoir laquelle des deux est appelée. La version non const est en général celle dont on a besoin la plus part du temps, la version const sert à pouvoir accéder aux propriétés avec un objet const tout en garantissant que celles-ci conserveront le caractère const (uniquement à la compil, bien sûr).

L'idée, c'est que la version non constante ne retourne pas une référence à un int, mais une classe qui ressemble à une telle référence, mais fera des choses supplémentaires.

Quand tu récupères une référence/proxy, tu ne sais pas si c'est pour la lire, ou l'écrire. Il est donc trop tôt pour prendre une décision à ce moment là. C'est au moment où tu utilises cette référence/proxy (par exemple, d'en l'opérateur = de ta classe de proxy) que tu sais ce que l'utilisateur va en faire.

Citation:

---

Envoyé par 3DArchi

La question me paraît étrange: vas-tu avoir un comportement différent entre la version const et l'autre? Peux-tu expliciter ton cas, car je n'ai jamais vu d'exemple de ce genre.

---

Le différence est entre un accès en lecture et un accès en écriture à l'objet (et utiliser const pour ça ne marche justement pas). Par exemple, on peut imaginer que quand on accède en écriture à l'objet, il mets à jour un flag dirty afin de se sauver quand on quitte le programme.

Quelque chose dans ce genre ?

Code:

---

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

class PosInt // Protège un entier pour qu'il soit toujours >= 0 { private: int & _ward; public: PosInt(int & ward) : _ward(ward) { if(_ward < 0) _ward = 0;}   friend int & operator=(int & i, const PosInt & pi); friend PosInt & operator=(PosInt & pi, const int i); };   int & operator=(int & i, const PosInt & pi) { return i = pi._ward; }   PosInt & operator=(PosInt & pi, const int i) { if(i < 0) // Absorbe les valeurs négatives pi._ward = 0; else pi._ward = i; return pi; }

---

Pourquoi pas, sauf que dans le cas en question, le proxy gardera probablement en plus une référence vers le conteneur d'où il vient, afin de pouvoir communiquer avec lui.