Le mot cl� const joue-t-il bien son r�le ?
En g�n�ral il est simple � comprendre et � utiliser, mais parfois il peut �tre tr�s complexe. Par exemple dans la stl, c'est pas �vident de s'y retrouver dans les iterator et les reference const et pas const (je parle de la lecture des sources pour "comprendre").

Un exemple.
J'ai une classe qui ne contient qu'un m_handle sur fichier et des m�thodes simples qui appelent l'api de windows (ou autre...). Toutes les m�thodes, sauf Open() et Close() (les seules qui modifient le membre m_handle), peuvent �tre const. M�me Write() alors que le fichier est modifi�. C'est logique me direz-vous, c'est une question de "concept".
Supposont maintenant que l'on d�rive cette classe pour y ajouter des membres comme m_seekposition, un buffer, un cache, etc. Bardaf, plus rien ne peut �tre const car m�me Read() modifie ces nouveaux membres. Et pour peu que les m�thodes de la classe de base �taient virtuelles, on ne sait plus trop si c'�tait "bien" d'en faire des "const" au d�part.

Un autre exemple, plus syntaxique.
Code : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class I
{
 friend class T;
 T * m_t;
 unsigned m_u;
public:
 ...
 unsigned Get() const
  { return m_t->Get(m_u); }
 ...
};
 
class T
{
 ...
 unsigned Get(unsigned p);
 ...
};
La m�thode I::Get() est const mais T::Get() ne l'est pas. Ainsi le compilateur accepte d'appeler une m�thode non const d'un de ses membres depuis une m�thode const. C'est "curieux" je trouve. Et �a m'arrange bien d'ailleurs car parfois c'est une prise de t�te pour savoir o� mettre const ou pas (ce qui se r�sume finalement, souvent et malheureusement par n'en mettre nulle part quand on n'a pas trop le temps de r�fl�chir).

Bref, comment faire pour bien impl�menter "const" ?
J'imagine que la r�ponse peut �tre vaste et sujette � de long d�bats...
(et pour une fois, la r�ponse ne sera pas "boost" )