faut-il supprimer le mot-clé const?

bonsoir,

Derrière l'aspect trollesque de la question, il y a, je crois, une question intéressante.

En effet, si dans une fonction membre constante, on peut:
1. modifier une variable membre déclarée mutable
2. modifier des variables globales | statiques
De plus, sachant qu'à n'importe quel endroit du code on peut casser la constance avec un const_cast, alors question: "à quoi sert le mot-clé const?"

Une réponse possible est: "ça ajoute de la sémantique, du sens, au code". Donc ça ne serait qu'à titre indicatif à l'attention de la personne qui lira le code?

Pourtant j'use et j'abuse de const, mais vous voyez, en y réfléchissant (et quand je suis de mauvaise humeur), je me dit: "si le stagiaire peut casser ma resplendissante const-conformité sans avoir besoin de modifier mon code.. à quoi bon?"
Du coup, je me demande si, plutôt que de supprimer le mot-clé const, il ne serait pas une bonne idée d'en ajouter un. Quelque chose du style pure_const, et qui serait intransigeant avec la const_conformité et qui interdirait les 3 points que j'ai énuméré au début.

Bonsoir,

disons que c'est une question de bon sens.
Et tout comme je peux faire un #define private public avant un include pour biaiser son contenu, je peux faire un const_cast pour passer outre la constance.
Les 2 cas me sont déjà arrivés, par moi ou déjà vu, est-ce pour autant qu'il faut le faire ? Surement pas ^^ Mais rien n'est tout blanc ou noir, alors avoir de tel hacks peut rendre service. :)
Mais ce sont et restent des hacks à mon sens.

Récemment un article est apparu et il proposait exactement l'inverse : tout soit const par défaut en C++ et marquer par un mot clé ce qui doit muter à l'instar des langages fonctionnels impurs qui autorisent les effets de bords, est-ce que cet article dit quelque chose à quelqu'un ? J'aimerai beaucoup le retrouver.

Le mot clef const ne sert-il pas aussi pour des optimisations lorsqu'il est utilise sur des methodes ?

Non, c'ets une vielle LU ça.

Un peu de culture à propos de const et mutable en C++11 :
http://channel9.msdn.com/posts/C-and...lank-and-blank

Citation:

---

Envoyé par r0d

1. modifier une variable membre déclarée mutable
2. modifier des variables globales | statiques
De plus, sachant qu'à n'importe quel endroit du code on peut casser la constance avec un const_cast, alors question: "à quoi sert le mot-clé const?"

---

Pour moi, le point 1 n'est pas une brisure de la "constitude", mais le fait qu'elle représente un const logique, et non pas un const physique. Il est tout à fait légitime quel'on puisse par exemple dans une fonction const modifier un mutex qui protège les accès à une donnée membre.

Pour le point 2, tu confonds const et pure. Une fonction pure ne doit pas modifier l'état global du programme, alors qu'une fonction const ne fait de promesses que par rapport à une variable en particulier. J'aimerais bien une prise en compte de la pureté en C++.

Le point 3, il faut faire attention : On n'a pas le droit de faire un const_cast sur une variable constante. Juste sur une variable non constante à laquelle on accèderait par un chemin constant. Mais sinon, je suis assez d'accord que const_cast est généralement problématique. Mais parfois, rarement, indispensable. Comme reinterpret_cast.

Citation:

---

Envoyé par JolyLoic

Pour moi, le point 1 n'est pas une brisure de la "constitude", mais le fait qu'elle représente un const logique, et non pas un const physique. Il est tout à fait légitime quel'on puisse par exemple dans une fonction const modifier un mutex qui protège les accès à une donnée membre.

---

En effet. D'autant plus que si une variable est déclarée mutable, le but c'est bien qu'elle puisse être modifiée dans les fonction membres constantes.

Citation:

---

Envoyé par JolyLoic

Pour le point 2, tu confonds const et pure. Une fonction pure ne doit pas modifier l'état global du programme, alors qu'une fonction const ne fait de promesses que par rapport à une variable en particulier. J'aimerais bien une prise en compte de la pureté en C++.

---

D'où mon idée de pure_const. En effet, la notion de pureté n'est pas vraiment utilisée en c++.
Mais globalement - et tu met bien le doigt dessus - il y a un manque ici à mon avis: il n'est pas possible d'avoir une fonction membre constante ET pure (à moins d'utiliser une fonction membre statique mais ce n'est pas exactement la même chose).
J'ai justement en tête l'exemple d'un parser sous forme de machine à état. L'algorithme de parsing est complexe, avec beaucoup de récursivité. Nous aimerions, dans certains cas, pouvoir s'assurer qu'une fonction membre ne va modifier ni l'état de son instance ni l'état du programme (lors de la déclaration des protocoles*, ie. avant de commencer l'implémentation: l'idée c'est de répartir l'implémentation des algos entre plusieurs développeurs, en fournissant un protocole qu'ils ne doivent pas modifier), et que ce ne soit surtout pas une fonction membre statique.



* j'utilise ici le mot protocole dans le sens de Lieberherr et Holland (le protocole de la classe C est l'ensemble des messages qui peuvent être envoyé à C et à ses instances. Avec, en gros, les messages représentent tout ce qui est public dans la classe C.)

Je suis d'accord avec JolyLoic, les variables membres mutables, à moins d'être mal employées, ont toujours un rôle de "bas niveau" indépendant des "vraies" données:

• Synchronisation
• Comptage de références
• Mise en cache/Évaluation paresseuse

J'ai peut-être oublié certains usages, mais normalement les variables membres "ordinaires" ne sont pas mutables et de tels mécanismes facilitent la const-correctness du reste (en évitant que de basses considérations système "empêchent" une méthode d'être const).

Plus préoccupant que le const_cast (qui lui, est facilement repérable par un grep), est le cast C-style; je serais partisan de le traiter comme un reinterpret_cast au lieu d'un cast universel si cela n'était pas un breaking change (ensuite, il y a des considérations comme le cast de void* en void(*)(), qui n'est permis qu'en C-style). Cela rendrait l'usage explicite du const_cast obligatoire, permettant de les repérer facilement.

const est le seul contrat dont on dispose en c++ « pur ». En plus, il a une sémantique bien définie et il est vérifié statiquement. C’est au contraire une garantie très forte, et qui manque dans beaucoup d’autres langages (c# et java en tête).

Citation:

---

J'ai justement en tête l'exemple d'un parser sous forme de machine à état. L'algorithme de parsing est complexe, avec beaucoup de récursivité. Nous aimerions, dans certains cas, pouvoir s'assurer qu'une fonction membre ne va modifier ni l'état de son instance ni l'état du programme (lors de la déclaration des protocoles*, ie. avant de commencer l'implémentation: l'idée c'est de répartir l'implémentation des algos entre plusieurs développeurs, en fournissant un protocole qu'ils ne doivent pas modifier), et que ce ne soit surtout pas une fonction membre statique.

---

Si la réaction de ton développeur, c’est de bricoler du const_cast pour passer outre const, change de développeur. Si c’est de l’externalisation à l’autre bout du monde, convainc tes dirigeants que c’est une connerie ;). Je pense que ce genre de trucs doit se régler avec des scripts grep.

L’autre solution si tu n’as pas confiance en const, c’est d’employer celles qui a cours dans les langages qui n’ont pas const : fournir un wrapper « read-only » de ta classe, et passer celui-ci en paramètre plutôt que l’objet lui même. À noter qu’un pervers pourra toujours s’en sortir pour quand même te modifier l’objet, mais ce sera plus dur qu’un simple const_cast.

Salut
Je partage l'avis de white_tentacle sur l'intérêt de const dans la vérification par le compilo d'une part contrat (d'ailleurs, white_tentacle, ce n'est pas le seul élément, un bon typage participe aussi de la définition du contrat vérifiable par le compilateur).
Si rien de standard n'existe pour l'instant en C++ pour contractualiser la pureté, il me semble que GCC a des attributs dans ses extensions pour cela.
@r0d, je ne comprends pas pourquoi tu dis qu'on ne peut avoir une fonction membre à la fois constante et pure. const n'engage rien en terme de pureté : ni dans un sens ni dans l'autre :koi:
Et si l'objet est un manque de confiance dans les tiers, de toute façon, en C++ tu pourras toujours hacker une zone mémoire.

Citation:

---

Envoyé par white_tentacle

À noter qu’un pervers pourra toujours s’en sortir pour quand même te modifier l’objet, mais ce sera plus dur qu’un simple const_cast.

---

On peut modifier des constantes même sans const_cast, si on le veut vraiment (et qu'on à pas peur du code dégueu)

Code:

---

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

#include <iostream>   class Foo { const int i; // privée et constante   public: Foo(): i(42) { }   void p() { std::cout << i << std::endl; } };     int main() { Foo f; int *pi = (int*)&f; f.p(); *pi = 0; // acces et modif d'un membre privé / constant   f.p(); return 0; }

---

Vivement le jour ou on pourra reellement planquer les membres prives sans pimpl idiom...

Citation:

---

Envoyé par 3DArchi

@r0d, je ne comprends pas pourquoi tu dis qu'on ne peut avoir une fonction membre à la fois constante et pure. const n'engage rien en terme de pureté : ni dans un sens ni dans l'autre :koi:

---

Justement, c'est bien cela que je dit: il n'y a aucune façon de déclarer une fonction membre comme pure. En fait, il n'y a aucune façon déclarer une fonction comme pure, qu'elle soit membre ou pas.

Avec constexpr, on ne peut pas s'en sortir?

par exemple, la fonction suivante est bien pure:

Code:

---

1 2 3

constexpr int half(int n){ return n/2; }

---

Salut,

Citation:

---

Envoyé par leternel

Avec constexpr, on ne peut pas s'en sortir?

par exemple, la fonction suivante est bien pure:

Code:

---

1 2 3

constexpr int half(int n){ return n/2; }

---

---

A vrai dire, ta fonction serait pure avec ou sans constexpr, car ce n'est pas le but de ce mot clé.

Le but de constexpr est d'informer le compilateur qu'il peut, sous certaines conditions, considérer que cette fonction renvoie une constante de compilation.

Cependant, cela n'oblige nullement le compilateur à la considérer effectivement comme une constante de compilation car il ne pourra la considérer comme telle que si n est lui-même une constante de compilation (ou le résultat d'une fonction déclarée comme constexpr qui prenait une constante de compilation, et l'on peut remonter comme cela assez haut :D ).

Si la valeur de n n'est pas une constante de compilation (par exemple parce que dépendante de la valeur d'une boucle ou d'une décision de l'utilisateur), la fonction sera considérée comme une fonction tout ce qu'il y a de plus normale et appelée de manière tout à fait classique.

Pour la question "Quand est-ce qu'une fonction constexpr est évaluée à la compilation ?", voir ce post : http://stackoverflow.com/q/14248235
et plus précisément cette réponse précisée par H.S. : http://stackoverflow.com/a/14248310

Citation:

---

Envoyé par r0d

Justement, c'est bien cela que je dit: il n'y a aucune façon de déclarer une fonction membre comme pure. En fait, il n'y a aucune façon déclarer une fonction comme pure, qu'elle soit membre ou pas.

---

non. c'est ce que dit Loïc. Il manque une façon pour indiquer qu'une fonction est pure en C ou en C++. Je crois que PC Lint (ou peut être d'autres outils d'analyse statique de code) permet de le détecter. Sinon, il reste toujours la bonne vieille (et peu sexy) revue de code.