Salut k-lo :)
Quote:
type nom_variable const;
Non, c'est
const type nom_variable;
Quote:
lorsque l'on est sur que cette donnée ne sera pas modifier après l'avoir défini ?
On en est pas sûr du tout :lol:
Quand on déclare une variable ou un membre const, cela veut dire que le codeur considère que ça doit être const et donc le rester.
Mais il y a toujours la possibilité d'un petit malin dégage le const par un const_cast. Attention je dis pas que c'est une bonne pratique. Dans ce cas c'en est même une très mauvaise. Selon la norme ça aboutit à un comportement indéterminé. Par exemple ça selon la machine et le compilo ça peut marcher. Ou bien par exemple le compilo s'est appuyé sur const pour placer la variable dans une zone de mémoire en lecture seule et là tu as un plantage :) Tu as aussi la possibilié qu'un fûté vienne attaquer ta variable const avec une petite routine en assembleur :) Donc tu n'es **SUR** de rien.
Par contre en déclarant const:
- tu exprimes clairement en tant qu'auteur du code que c'est const et que ça doit le rester.
- tu peux donc compter que ça restera const si tu as affaire à d'autres codeurs bien élévés et qui connaissent C++. (Oui je sais ça devient rare... mais il en reste encore heureusement :) )
Tu augmentes la sécurité et le cohérence de ton code, le compilateur t'interdisant (sauf si tu joues toi même avec const_cast bien entendu) de modifier une variable const et ainsi de te contredire mille lignes de code et un coup de fatigue plus loin
- tu permets au compilo de procéder tout seul comme un grand, telle que celle que j'ai évoqué plus haut, ou encore la suppression pure et simple d'objets temporaires, ou encore, etc, etc :)
Quote:
Deplus si on a défini une variable "string str1;" la méthode getStr1() sera plutot écrit sous cette forme
string& getStr1() { return str1; }
plutot que
string& getStr1() const {return str1;}
Ce n'est pas si simple
Quand tu écris
string& getStr1() { return str1; }
Tu retournes une référence donc cela veut dire que l'appelant peut modifier l'état interne de l'objet puisqu'il peut modifier le membre référencé. Mais ce n'est probablement pas ce que tu veux car tu ne voudras pas violer les principes d'encapsulation les plus élémentaires en donnant ainsi accès à une variable à priori private.
Si tu écris:
string& getStr1() const {return str1;}
Alors tu annonces que getStrr1 ne modifiera pas l'état de ton objet ce qui est franchement faux puisque on peut modifier la chaîne membre comme dit plus haut donc modifier l'état interne de l'objet. Donc ce que tu dois écrire est:
const string& getStr1() const {return str1;}
Et là c'est ok.
En revanche dans le code que j'ai donné dans mon post précédent tu as l'équivalent de:
string getStr1() const {return str1;}
Là on retourne une copie du membre. Si l'appelant modifie la copie, l'état de l'objet reste quand même inchangé et donc la déclaration qui dit que getStr1 ne modifie pas l'état interne de l'objet est ok :)
Salut k-lo :)
Non, c'est
const type nom_variable;
On en est pas sûr du tout :lol:
Quand on déclare une variable ou un membre const, cela veut dire que le codeur considère que ça doit être const et donc le rester.
Mais il y a toujours la possibilité d'un petit malin dégage le const par un const_cast. Attention je dis pas que c'est une bonne pratique. Dans ce cas c'en est même une très mauvaise. Selon la norme ça aboutit à un comportement indéterminé. Par exemple ça selon la machine et le compilo ça peut marcher. Ou bien par exemple le compilo s'est appuyé sur const pour placer la variable dans une zone de mémoire en lecture seule et là tu as un plantage :) Tu as aussi la possibilié qu'un fûté vienne attaquer ta variable const avec une petite routine en assembleur :) Donc tu n'es **SUR** de rien.
Par contre en déclarant const:
- tu exprimes clairement en tant qu'auteur du code que c'est const et que ça doit le rester.
- tu peux donc compter que ça restera const si tu as affaire à d'autres codeurs bien élévés et qui connaissent C++. (Oui je sais ça devient rare... mais il en reste encore heureusement :) )
Tu augmentes la sécurité et le cohérence de ton code, le compilateur t'interdisant (sauf si tu joues toi même avec const_cast bien entendu) de modifier une variable const et ainsi de te contredire mille lignes de code et un coup de fatigue plus loin
- tu permets au compilo de procéder tout seul comme un grand, telle que celle que j'ai évoqué plus haut, ou encore la suppression pure et simple d'objets temporaires, ou encore, etc, etc :)
Ce n'est pas si simple
Quand tu écris
string& getStr1() { return str1; }Tu retournes une référence donc cela veut dire que l'appelant peut modifier l'état interne de l'objet puisqu'il peut modifier le membre référencé. Mais ce n'est probablement pas ce que tu veux car tu ne voudras pas violer les principes d'encapsulation les plus élémentaires en donnant ainsi accès à une variable à priori private.
Si tu écris:
string& getStr1() const {return str1;}
Alors tu annonces que getStrr1 ne modifiera pas l'état de ton objet ce qui est franchement faux puisque on peut modifier la chaîne membre comme dit plus haut donc modifier l'état interne de l'objet. Donc ce que tu dois écrire est:
const string& getStr1() const {return str1;}Et là c'est ok.En revanche dans le code que j'ai donné dans mon post précédent tu as l'équivalent de:
string getStr1() const {return str1;}
Là on retourne une copie du membre. Si l'appelant modifie la copie, l'état de l'objet reste quand même inchangé et donc la déclaration qui dit que getStr1 ne modifie pas l'état interne de l'objet est ok :)