Dans ce cas-ci, rien en effet. Je me suis contenté d'obliger la fonction DoSomething() à n'utiliser que des méthodes garantissant qu'elles ne modifient pas l'objet. Ces méthodes peuvent en effet contenir des erreurs, mais c'est un autre problème.
Considérons donc ce problème: pour le développeur de la méthode Display(), comment peut-il s'assurer qu'il ne modifie pas l'objet par inadvertance? Encore une fois, c'est possible en séparant la classe en partie immuable/partie variable:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| class MyTypeReadOnly {
protected:
virtual int getX() = 0;
virtual float getF() = 0;
public:
// La classe n'a que des getters, donc impossible de modifier l'objet
void Display() { cout << getX() << " " << getF() << endl; }
};
class MyType : public MyTypeReadOnly {
int m_x;
float m_f;
protected:
int getX() { return m_x; }
float getF() { return m_f; }
public:
// La classe a accès à ses membres de données, donc elle peut le modifier
void Initialize() { m_x = 0; m_f = 0.0f; }
}; |
À moins que le développeur de MyType ne modifie l'objet dans les getters, ce qui est une erreur très évidente (à ce titre, il pourrait aussi bien faire des const_cast pour contourner const), la méthode Display n'a aucun moyen de modifier l'objet.
Oui. Const ne rend pas une classe immuable, const donne accès à une instance de manière immuable (il limite l'usage aux fonctions const). Or, donner accès à une instance de manière immuable, c'est bien ce que j'ai fait ici en présentant une interface immuable à mon instance.
Dans le contre-exemple que tu donnes, si vector<T> avait une interface immuable, il me suffirait de le passer en tant que cette interface plutôt qu'en tant que const vector<T> pour arriver à la même garantie.
... et est donc totalement inutile? En fait oui, mettre des const sur les méthodes d'accès oblige toute méthode appelée par ces méthodes à être const aussi, de façon récursive à l'infini. Donc, l'impact sur le code est potentiellement énorme. Tandis que absence de const + interfaces immuables spécifie un contrainte
localisée et
spécifique.
Envoyé par gl
Répondre avec citation
je semi-déconne :o
: matrice qui relie l'état précédent k-1 à l'état actuel k
: entrée de commande
: matrice qui relie l'entrée de commande u à l'état x
: matrice d'estimation a priori de la covariance de l'erreur
: matrice d'estimation a posteriori de la covariance de l'erreur
: matrice de covariance du bruit de process
) là où... trois auraient suffit.
A méditer: La solution la plus simple est toujours la moins compliquée
.
Partager