Discussion :

[Invité]

Vous éveillez ma curiosité là ! Qu'est-ce que ça apporterait de plus que je mette la variable en const ?

Ca parait anodin, mais c'est le pacte, le contrat, que remplit ma fonction.

A l'inverse, si l'argument n'est pas const, je n'ai absolument aucune assurance qu'il ne sera pas modifié.

Dans le cadre d'un TP de cours qui fait 2 méthodes et 15 lignes c'est sur que ça parait stupide.
Quand on parle d'une appli de plusieurs années et millions de lignes...

En gros ça plante !!! Et c'est mieux que d'avoir un bug presque introuvable à 3 jours d'une livraison (parce que le programme ne commence à planter que 3 jours avant la livraison )...

[koala01]

En fait, le passage d'un argument sous une forme constante permet de dire "attention, on ne peut absolument pas aller modifier l'état de cet argument". C'est ce que l'on appelle "imposer un invariant".

Ca, c'est quelque chose que le compilateur est en mesure de comprendre, et qu'il est en mesure de faire respecter. Comment En s'assurant que toutes les fonctions qui utiliseront l'argument ne sera pas modifié.

C'est à dire qu'il pourra vérifier que tu n'essaye pas de transmettre l'argument à une fonction qui le prendrait sous la forme d'une référence non constante (car les modifications seraient reportées à ton argument) et que tu n'appelle que des fonctions qui se sont engagées à ne pas modifier l'état de ton argument (les fonctions membres déclarées constantes).

Car, si tu essayes de transmettre un argument constant à une fonction qui prend la forme non constante, le compilateur se plaindra qu'il ne peux pas convertir un const TonType & en un TonType et que, pour les fonctions membres qui ne sont pas déclarées constantes, il se plaindra que tu utilises un "this constant". Quoi qu'il en soit, le compilateur refusera automatiquement que tu utilises ton argument constant avec n'importe quelle fonction pour laquelle "il y a risque qu'il soit modifié". Avec une telle garantie, tu t'assures que les seules modifications qui surviennent à tes différents objets sont des modifications qui ont été clairement voulues (ou, à tout le moins qui surviennent dans un contexte dans lequel la modification de ton objet a bel et bien été envisagée) .

Et comme le compilateur sera toujours plus têtu que toi, tu feras en sorte de le satisfaire, si tu veux que ton programme compile

[_zzyx_]

Deux remarques/questions sur ce sujets

* Je crois que const n'est pas une garantie suffisante que l'objet ne soit en aucun cas modifié (soit par le biais d'un const_cast, soit par un débordement de pointeurs) bon, le premier cas devrait être rare et controlé, le second est généralement le signe d'un programme qui a un comportement non déterministe. est

* J'ai toujours crus, que const était aussi un indice donné au compilateur pour faire des optimisations (car il sait que telle variable ne sera pas modifié), or personne n'en parle ici. qu'en est il en vrai. ?

[koala01]

Deux remarques/questions sur ce sujets

* Je crois que const n'est pas une garantie suffisante que l'objet ne soit en aucun cas modifié (soit par le biais d'un const_cast, soit par un débordement de pointeurs) bon, le premier cas devrait être rare et controlé, le second est généralement le signe d'un programme qui a un comportement non déterministe. est

Il est clair que le mot clé const ne peut donner une garantie que sur ce qui est "correctement" codé/programmé.

Si le développeur fait une connerie et tente d'accéder à une adresse mémoire à laquelle il n'aurait jamais du tenter d'accéder, ll est évident que rien ni personne ne pourra le sauver. Le seul moyen pour résoudre le problème passera par une longue et fastidieuse séance de débogage .

Le langage et le compilateur sont des alliés de choix quand il s'agit d'appliquer une logique correcte, mais ne peuvent effectivement rien pour nous si l'on fait des conneries de conception

* J'ai toujours crus, que const était aussi un indice donné au compilateur pour faire des optimisations (car il sait que telle variable ne sera pas modifié), or personne n'en parle ici. qu'en est il en vrai. ?

Oui, c'est tout à fait vrai.

Il est, par exemple, tout à fait en mesure d'évaluer des expressions mathématiques simples ( A =(X+Y)*Z, par exemple) et définir directement le résultat de l'expression comme valeur pour A si A, X, Y et Z sont constants.

Ainsi, si X vaut 2, Y vaut 3 et Z vaut 4, la valeur de A sera directement définie "en dur" à 20 car cela correspond bel et bien au résultat de l'expression indiquée. Notes d'ailleurs que ce n'est qu'un des exemples les plus simples d'optimisation dont le compilateur est capable

Ceci dit, si on n'a pas parlé de cet avantage, c'est "simplement" parce que l'intérêt de la chose n'est pas primordial lorsqu'il s'agit d'expliquer simplement le bénéfice que l'on retire à respecter la const-correctness. C'est la "cerise sur le gâteau"

[white_tentacle]

Il est, par exemple, tout à fait en mesure d'évaluer des expressions mathématiques simples ( A =(X+Y)*Z, par exemple) et définir directement le résultat de l'expression comme valeur pour A si A, X, Y et Z sont constants.

C’est plus ou moins vrai, en fait. De nos jours, les compilateurs n’utilisent plus l’indication const pour leurs optimisations, mais déterminent eux-même si la valeur change (comme il faut le faire de toute manière à cause de const_cast, autant l’appliquer à toutes les variables).

En revanche, c++11 a introduit constexpr, qui lui te garantit que l’expression sera évaluée (et donc, optimisée) à la compilation.