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" )