Penser en C++

L'astuce avec la définition de pointeur, comme avec toute définition compliquée, est de la lire en partant de l'identifiant jusque vers la fin de la définition. Le mot-clef const est lié à l'élément dont il est le « plus proche ». Donc, si vous voulez éviter tout changement à l'objet pointé, vous écrivez une définition ainsi :

const int* u;

En partant de l'identifiant, nous lisons « u est un pointeur, qui pointe vers un constint.” Ici, il n'y a pas besoin d'initialisation, car vous dites que u peut pointer vers n'importe quoi (c'est-à-dire qu'il n'est pas const), mais l'élément vers lequel il pointe ne peut pas être changé.

Voici la partie un peu déroutante. Vous pourriez penser que pour rendre le pointeur lui-même inmodifiable, c'est-à-dire pour éviter toute modification de l'adresse contenue dans u, il suffit de déplacer le const de l'autre côté du int comme ceci :

int const* v;

Ce n'est pas du tout idiot de penser que ceci devait se lire « v est un pointeur const vers un int.”. Toutefois, la vraie façon de le lire est « v est un pointeur ordinaire vers un int qui se trouve être const.”. Donc, le const s'est lié au int à nouveau, et l'effet est le même que dans la définition précédente. Le fait que ces deux définitions soient les mêmes est un peu déroutant ; pour éviter cette confusion au lecteur, vous devriez probablement n'utiliser que la première forme.

Pour rendre le pointeur lui-même const, vous devez placer le mot-clef const à droite de l'étoile *, comme ceci :

int d = 1;
int* const w = &d;

À présent on lit : « w est un pointeur de type const, qui pointe vers un int.”. Comme le pointeur lui-même est à présent le const, le compilateur impose qu'il lui soit assigné une valeur initiale qui restera inchangée durant toute la vie de ce pointeur. Il est possible, par contre, de modifier ce vers quoi pointe cette valeur en disant :

*w = 2;

Vous pouvez également créer un pointeur const vers un objet const en utilisant une de ces deux syntaxes licites :

int d = 1;
const int* const x = &d;  // (1)
int const* const x2 = &d; // (2)

À présent, ni le pointeur ni l'objet ne peuvent être modifiés.

Certaines personnes affirment que la deuxième forme est plus cohérente parce que le const est toujours placé à droite de ce qu'il modifie. Vous n'avez qu'à décider ce qui est le plus clair pour votre manière de coder.

Voici les lignes ci-dessus dans un fichier compilable :

//: C08:ConstPointers.cpp
const int* u;
int const* v;
int d = 1;
int* const w = &d;
const int* const x = &d;  // (1)
int const* const x2 = &d; // (2)
int main() {} ///:~

Formatage

Ce livre insiste sur le fait de ne mettre qu'une définition de pointeur par ligne, et d'initialiser chaque pointeur au point de définition lorsque c'est possible. À cause de cela, le style de formatage qui consiste à “attacher” le ‘ *' au type de donnée est possible :

int* u = &i;

comme siint* était un type en soi. Ceci rend le code plus facile à comprendre, mais malheureusement ce n'est pas comme cela que les choses fonctionnent vraiment. Le ‘ *' est en fait attaché à l'identifiant, pas au type. Il peut être placé n'importe où entre le nom et l'identifiant. Vous pourriez donc écrire cela :

int *u = &i, v = 0;

qui crée un int* u, comme précédemment, et un int v qui n'est pas un pointeur. Comme les lecteurs trouvent souvent cela déroutant, il est recommandable de suivre la forme proposée dans ce livre.

Le C++ est très spécial en ce qui concerne la vérification de type, et ce jusqu'à l'assignation de pointeur. Vous pouvez assigner l'adresse d'un objet non- const à un pointeur const parce que vous promettez simplement de ne pas changer quelque chose qui peut se changer. Par contre, vous ne pouvez pas assigner l'adresse d'un objet const à un pointeur non- const car alors vous dites que vous pourriez changer l'objet via le pointeur. Bien sûr, vous pouvez toujours utiliser la conversion de type ( cast, ndt) pour forcer une telle assignation, mais c'est une mauvaise habitude de programmation, car vous brisez la const ance de l'objet ainsi que la promesse de sécurité faite par le const. Par exemple :

//: C08:PointerAssignment.cpp
int d = 1;
const int e = 2;
int* u = &d; // OK -- d n'est pas const
//! int* v = &e; // Illicite -- e est const
int* w = (int*)&e; // Licite mais mauvaise habitude
int main() {} ///:~

Bien que C++ aide à prévenir les erreurs, il ne vous protège pas de vous-même si vous voulez enfreindre les mécanismes de sécurité.

Les tableaux de caractères littéraux

Le cas où la const ance stricte n'est pas imposée, est le cas des tableaux de caractères littéraux. Vous pouvez dire :

char* cp = "Salut";

et le compilateur l'acceptera sans se plaindre. C'est techniquement une erreur, car un tableau de caractères littéraux (ici, “Salut”) est créé par le compilateur comme un tableau de caractères constant, et le résultat du tableau de caractère avec des guillemets est son adresse de début en mémoire. Modifier n'importe quel caractère dans le tableau constitue une erreur d'exécution, bien que tous les compilateurs n'imposent pas cela correctement.

Ainsi, les tableaux de caractères littéraux sont réellement des tableaux de caractères constants. Évidemment, le compilateur vous laisse vous en tirer en les traitant comme des non- const car il y a beaucoup de code C qui repose là-dessus. Toutefois, si vous tentez de modifier la valeur dans un tableau de caractères littéral, le comportement n'est pas défini, bien que cela fonctionnera probablement sur beaucoup de machines.

Si vous voulez être capable de modifier la chaine, mettez-la dans un tableau :

char cp[] = "howdy";

Comme les compilateurs ne font généralement pas la différence, on ne vous rappellera pas d'utiliser cette dernière forme et l'argument devient relativement subtil.

Vous pouvez spécifier que les arguments de fonction soient const quand vous les passez par valeur, comme dans ce cas

void f1(const int i) {
  i++; // Illégal - erreur à la compilation
  }

mais qu'est-ce que cela veut dire ? Vous faites la promesse que la valeur originale de la variable ne sera pas modifiée par la fonction f1( ). Toutefois, comme l'argument est passé par valeur, vous faites immédiatement une copie de la variable originale, donc la promesse au client est implicitement tenue.

Dans la fonction, const prend le sens : l'argument ne peut être changé. C'est donc vraiment un outil pour le créateur de la fonction, et pas pour l'appelant.

Pour éviter la confusion à l'appelant, vous pouvez rendre l'argument const à l'intérieur de la fonction, plutôt que dans la liste des arguments. Vous pourriez faire cela avec un pointeur, mais une syntaxe plus jolie est utilisable avec les références, sujet qui sera développé en détail au Chapitre 11. Brièvement, une référence est comme un pointeur constant qui est automatiquement déréférencé, et qui a donc l'effet d'être un alias vers un objet. Pour créer une référence, on utilise le & dans la définition. Finalement, la définition de fonction claire ressemble à ceci :

void f2(int ic) {
  const int& i = ic;
  i++;  // Illégal - erreur à la compilation} 
}

Une fois encore, vous obtiendrez un message d'erreur, mais cette foi-ci la const ance de l'objet local ne fait pas partie de la signature de la fonction ; elle n'a de sens que pour l'implémentation de la fonction et est ainsi dissimulée au client.

Une réalité similaire s'applique aux valeurs retournées. Si vous dites qu'une valeur retournée par une fonction est const  :

const int g();

vous promettez que la valeur originale (dans la portée de la fonction) ne sera pas modifiée. Une fois encore, comme vous la retournez par valeurs, elle est copiée si bien que la valeur originale ne pourra jamais être modifiée via la valeur retournée.

Au premier abord, cela peut faire paraître la déclaration const dénuée de sens. Vous pouvez constater le manque apparent d'effet de retourner des const par valeurs dans cet exemple :

//: C08:Constval.cpp
// Retourner des const par valeur
// n'a pas de sens pour les types prédéfinis
 
int f3() { return 1; }
const int f4() { return 1; }
 
int main() {
  const int j = f3(); // Marche bien
  int k = f4(); //, Mais celui-ci marche bien également !
} ///:~

Pour les types prédéfinis, cela n'a aucune importance que vous retourniez une valeur comme const, donc vous devriez éviter la confusion au programmeur client et oublier const quand vous retournez un type prédéfini par valeur.

Retourner un const par valeur devient important quand vous traitez des types définis par l'utilisateur. Si une fonction retourne comme const un objet de classe , la valeur de retour de cette fonction ne peut pas être une lvalue (c'est-à-dire, elle ne peut être assignée ou modifiée autrement). Par exemple :

//: C08:ConstReturnValues.cpp
// Constante retournée par valeur
// Le résultat ne peut être utilisé comme une lvalue
 
class X {
  int i;
public:
  X(int ii = 0);
  void modify();
};
 
X::X(int ii) { i = ii; }
 
void X::modify() { i++; }
 
X f5() {
  return X();
}
 
const X f6() {
  return X();
}
 
void f7(X& x) { // Passé par référence pas const
  x.modify();
}
 
int main() {
  f5() = X(1); // OK -- valeur de retour non const
  f5().modify(); // OK
//!  f7(f5()); // Provoque warning ou erreur
// Cause des erreurs de compilation :
//!  f7(f5());
//!  f6() = X(1);
//!  f6().modify();
//!  f7(f6());
} ///:~

f5( ) renvoie un objet non- const, alors que f6( ) renvoie un objet const X. Seule la valeur retournée qui n'est pas const peut être utilisée comme une lvalue. Ainsi, il est important d'utiliser const quand vous retournez un objet par valeur si vous voulez éviter son utilisation comme lvalue.

La raison pour laquelle const ne veut rien dire quand vous renvoyez un type prédéfini par valeur est que le compilateur empêche déjà qu'il soit utilisé comme lvalue (parce que c'est toujours une valeur, et pas une variable). C'est seulement lorsque vous renvoyez des types définis par l'utilisateur par valeur que cela devient un problème.

La fonction f7( ) prend son argument comme une référence(un moyen supplémentaire de manipuler les adresses en C++ qui sera le sujet du chapitre 11) qui n'est pas de type const. C'est en fait la même chose que d'utiliser un pointeur qui ne soit pas non plus de type const; seule la syntaxe est différente. La raison pour laquelle ce code ne compilera pas en C++ est qu'il y a création d'une variable temporaire.

Les variables temporaires

Parfois, pendant l'évaluation d'une expression, le compilateur doit créer des objets temporaires. Ce sont des objets comme n'importe quels autres : ils nécessitent un stockage et doivent être construits et détruits. La différence est que vous ne les voyez jamais ; le compilateur a la charge de décider s'ils sont nécessaires et de fixer les détails de leur existence. Mais il faut noter une chose en ce qui concerne les variables temporaires : elles sont automatiquement const. Comme vous ne serez généralement pas capable de manipuler un objet temporaire, dire de faire quelque chose qui le modifierait est presque à coup sûr une erreur parce que vous ne serez pas capable d'utiliser cette information. En rendant tous les temporaires automatiquement const, le compilateur vous informe quand vous commettez cette erreur.

Dans l'exemple ci-dessus, f5( ) renvoie un objet X qui n'est pas const. Mais dans l'expression :

f7(f5());

Le compilateur doit créer un objet temporaire pour retenir la valeur de f5( ) afin qu'elle soit passée à f7( ). Cela serait correct si f7( ) prenait ses arguments par valeur ; alors, l'objet temporaire serait copié dans f7( ) et ce qui arriverait au X temporaire n'aurait aucune importance. Cependant, f7( ) prend ses arguments par référence, ce qui signifie dans cet exemple qu'il prend l'adresse du X temporaire. Comme f7( ) ne prend pas ses arguments par référence de type const, elle a la permission de modifier l'objet temporaire. Mais le compilateur sait que l'objet temporaire disparaîtra dès que l'évaluation de l'expression sera achevée, et ainsi toute modification que vous ferez au X temporaire sera perdue. En faisant de tous les objets temporaires des const, cette situation produit un message d'erreur de compilation, afin que vous ne rencontriez pas un bug qui serait très difficile à trouver.

Toutefois, notez les expressions licites :

  f5() = X(1);
  f5().modify();

Bien que ces passages fassent appel au compilateur, ils sont problématiques. f5( ) renvoie un objet X, et pour que le compilateur satisfasse les expressions ci-dessus il doit créer un objet temporaire pour retenir cette valeur temporaire. Ainsi, dans les deux expressions l'objet temporaire est modifié, et dès que l'expression est terminée, l'objet temporaire est détruit. En conséquence, les modifications sont perdues et ce code est probablement un bug ; mais le compilateur ne vous dit rien. Des expressions comme celles-ci sont suffisamment simples pour que vous détectiez le problème, mais quand les choses deviennent plus compliquées, il est possible qu'un bug se glisse à travers ces fissures.

La façon dont la const ance des objets d'une classe est préservée est montrée plus loin dans ce chapitre.

Si vous passez ou retournez une adresse (un pointeur ou une référence), le programmeur client peut la prendre et modifier sa valeur originale. Si vous rendez le pointeur ou la référence const, vous l'en empêchez, ce qui peut éviter quelques douleurs. En fait, lorsque vous passez une adresse à une fonction, vous devriez, autant que possible, en faire un const. Si vous ne le faites pas, vous excluez la possibilité d'utiliser cette fonction avec quelque type const que ce soit.

Le choix de retourner un pointeur ou une référence comme const dépend de ce que vous voulez autoriser le programmeur client à faire avec. Voici un exemple qui démontre l'usage de pointeurs const comme arguments de fonction et valeurs retournées :

//: C08:ConstPointer.cpp
// Pointeur constants comme arguments ou retournés
 
void t(int*) {}
 
void u(const int* cip) {
//!  *cip = 2; // Illicite - modifie la valeur
  int i = *cip; // OK -- copie la valeur
//!  int* ip2 = cip; // Illicite : pas const
}
 
const char* v() {
  // Retourne l'adresse du tableau de caractère static :
  return "result of function v()";
}
 
const int* const w() {
  static int i;
  return &i;
}
 
int main() {
  int x = 0;
  int* ip = &x;
  const int* cip = &x;
  t(ip);  // OK
//!  t(cip); // Pas bon
  u(ip);  // OK
  u(cip); // Egalement OK
//!  char* cp = v(); // Pas bon
  const char* ccp = v(); // OK
//!  int* ip2 = w(); // Pas bon
  const int* const ccip = w(); // OK
  const int* cip2 = w(); // OK
//!  *w() = 1; // Pas bon
} ///:~

La fonction t( ) prend un pointeur ordinaire (non- const) comme argument, et u( ) prend un pointeur const. Dans u( ) vous pouvez constater qu'essayer de modifier la destination du pointeur const est illicite, mais vous pouvez bien sûr copier l'information dans une variable non const ante. Le compilateur vous empêche également de créer un pointeur non- const ant en utilisant l'adresse stockée dans un pointeur de type const.

Les fonctions v( ) et w( ) testent la sémantique d'une valeur de retour. v( ) retourne un constchar* créé à partir d'un tableau de caractères. Cette déclaration produit vraiment l'adresse du tableau de caractères, après que le compilateur l'ait créé et stocké dans l'aire de stockage statique. Comme mentionné plus haut, ce tableau de caractères est techniquement une constante, ce qui est correctement exprimé par la valeur de retour de v( ).

La valeur retournée par w( ) requiert que le pointeur et ce vers quoi il pointe soient des const. Comme avec v( ), la valeur retournée par w( ) est valide après le retour de la fonction uniquement parce qu'elle est static. Vous ne devez jamais renvoyer des pointeurs vers des variables de pile locales parce qu'ils seront invalides après le retour de la fonction et le nettoyage de la pile. (Un autre pointeur habituel que vous pouvez renvoyer est l'adresse du stockage alloué sur le tas, qui est toujours valide après le retour de la fonction).

Dans main( ), les fonctions sont testées avec divers arguments. Vous pouvez constater que t( ) acceptera un pointeur non- const comme argument, mais si vous essayez de lui passer un pointeur vers un const, il n'y a aucune garantie que t( ) laissera le pointeur tranquille, ce qui fait que le compilateur génère un message d'erreur. u( ) prend un pointeur const, et acceptera donc les deux types d'arguments. Ainsi, une fonction qui prend un pointeur const est plus générale qu'une fonction qui n'en prend pas.

Comme prévu, la valeur de retour de v( ) peut être assignée uniquement à un pointeur vers un const. Vous vous attendriez aussi à ce que le compilateur refuse d'assigner la valeur de retour de w( ) à un pointeur non- const, et accepte un const int* const, mais il accepte en fait également un const int*, qui ne correspond pas exactement au type retourné. Encore une fois, comme la valeur (qui est l'adresse contenue dans le pointeur) est copiée, la promesse que la variable originale ne sera pas atteinte est automatiquement tenue. Ainsi, le second const dans const int* const n'a de sens que quand vous essayez de l'utiliser comme une lvalue, auquel cas le compilateur vous en empêche.

Passage d'argument standard

En C, il est très courant de passer par valeur, et quand vous voulez passer une adresse votre seule possibilité est d'utiliser un pointeur (42). Toutefois, aucune de ces approches n'est préférée en C++. Au lieu de cela, votre premier choix quand vous passez un argument est de le passer par référence, et par référence de type const, qui plus est. Pour le programmeur client, la syntaxe est identique à celle du passage par valeur, et il n'y a donc aucune confusion à propos des pointeurs ; ils n'ont même pas besoin de penser aux pointeurs. Pour le créateur de la fonction, passer une adresse est pratiquement toujours plus efficace que passer un objet de classe entier, et si vous passez par référence de type const, cela signifie que votre fonction ne changera pas la destination de cette adresse, ce qui fait que l'effet du point de vue du programmeur client est exactement le même que de passer par valeur (c'est juste plus efficace).

À cause de la syntaxe des références (cela ressemble à un passage par valeur pour l'appelant) il est possible de passer un objet temporaire à une fonction qui prend une référence de type const, alors que vous ne pouvez jamais passer un objet temporaire à une fonction qui prend un pointeur ; avec un pointeur, l'adresse doit être prise explicitement. Ainsi, le passage par référence crée une nouvelle situation qui n'existe jamais en C : un objet temporaire, qui est toujours const, peut voir son adresse passée à une fonction. C'est pourquoi, pour permettre aux objets temporaires d'être passés aux fonctions par référence, l'argument doit être une référence de type const. L'exemple suivant le démontre :

//: C08:ConstTemporary.cpp
// Les temporaires sont des <b>const</b>
 
class X {};
 
X f() { return X(); } // Retour par valeur
 
void g1(X&) {} // Passage par référence de type non-const
void g2(const X&) {} // Passage par référence de type const
 
int main() {
  // Erreur : const temporaire créé par f()
//!  g1(f());
  // OK: g2 prend une référence const
  g2(f());
} ///:~

f( ) retourne un objet de class Xpar valeur. Cela signifie que quand vous prenez immédiatement la valeur de retour de f( ) et que vous la passez à une autre fonction comme dans l'appel de g1( ) et g2( ), un objet temporaire est créé et cet objet temporaire est de type const. Ainsi, l'appel dans g1( ) est une erreur parce que g1( ) ne prend pas de référence de type const, mais l'appel à g2( ) est correct.

Un des endroits où vous aimeriez utiliser un const pour les expressions constantes est à l'intérieur des classes. L'exemple type est quand vous créez un tableau dans une classe et vous voulez utiliser un const à la place d'un #define pour définir la taille du tableau et l'utiliser dans des calculs impliquant le tableau. La taille du tableau est quelque chose que vous aimeriez garder caché dans la classe, de telle sorte que si vous utilisiez un nom comme taille, par exemple, vous puissiez l'utiliser également dans une autre classe sans qu'il y ait de conflit. Le préprocesseur traite tous les #define comme globaux à partir du point où ils sont définis, donc ils n'auront pas l'effet désiré.

Vous pourriez supposer que le choix logique est de placer un const dans la classe. Ceci ne produit pas le résultat escompté. Dans une classe, const revient partiellement à son sens en C. Il alloue un espace de stockage dans chaque objet et représente une valeur qui ne peut être initialisée qu'une fois et ne peut changer par la suite. L'usage de const dans une classe signifie « Ceci est constant pour toute la durée de vie de l'objet ». Toutefois, chaque objet différent peut contenir une valeur différente pour cette constante.

Ainsi, quand vous créez un const ordinaire (pas static) dans une classe, vous ne pouvez pas lui donner une valeur initiale. Cette initialisation doit avoir lieu dans le constructeur, bien sûr, mais à un endroit spécial du constructeur. Parce qu'un const doit être initialisé au point où il est créé, il doit déjà l'être dans le corps du constructeur. Autrement vous risqueriez d'avoir à attendre jusqu'à un certain point du constructeur et le const resterait non initialisé quelque temps. En outre, il n'y aurait rien qui vous empêcherait de modifier la valeur du const à différents endroits du corps du constructeur.

La liste d'initialisation du constructeur

Le point d'initialisation spécial est appelé liste d'initialisation du constructeur, et a été initialement développé pour être utilisé dans l'héritage (couvert au Chapitre 14). La liste d'initialisation du constructeur - qui, comme son nom l'indique, n'intervient que dans la définition du constructeur - est une liste « d'appels de constructeurs » qui a lieu après la liste des arguments et deux points, mais avant l'accolade ouvrante du corps du constructeur. Ceci pour vous rappeler que l'initialisation dans la liste a lieu avant que tout code du corps du constructeur ne soit exécuté. C'est là qu'il faut mettre toutes les initialisations de const. La forme correcte pour const dans une classe est montrée ici :

//: C08:ConstInitialization.cpp
// Initialiser des const dans les classes
#include <iostream>
using namespace std;
 
class Fred {
  const int size;
public:
  Fred(int sz);
  void print();
};
 
Fred::Fred(int sz) : size(sz) {}
void Fred::print() { cout << size << endl; }
 
int main() {
  Fred a(1), b(2), c(3);
  a.print(), b.print(), c.print();
} ///:~

La forme de la liste d'initialisation du constructeur montrée ci-dessus est déroutante au début parce que vous n'êtes pas habitués à voir un type prédéfini traité comme s'il avait un constructeur.

“Constructeurs” pour types prédéfinis

Comme le langage se développait et que plus d'effort était fourni pour rendre les types définis par l'utilisatur plus ressemblant aux types prédéfinis, il devint clair qu'il y avait des fois où il était utile de rendre des types prédéfinis semblables aux types définis par l'utilisateur. Dans la liste d'initialisation du constructeur, vous pouvez traiter un type prédéfini comme s'il avait un constructeur, comme ceci :

//: C08:BuiltInTypeConstructors.cpp
#include <iostream>
using namespace std;
 
class B {
  int i;
public:
  B(int ii);
  void print();
};
 
B::B(int ii) : i(ii) {}
void B::print() { cout << i << endl; }
 
int main() {
  B a(1), b(2);
  float pi(3.14159);
  a.print(); b.print();
  cout << pi << endl;
} ///:~

C'est critique quand on initialise des données membres const car elles doivent être initialisées avant l'entrée dans le corps de la fonction.

Il était logique d'étendre ce « constructeur » pour types prédéfinis (qui signifie simplement allocation) au cas général, ce qui explique pourquoi la définition float pi(3.14159) fonctionne dans le code ci-dessus.

Il est souvent utile d'encapsuler un type prédéfini dans une classe pour garantir son initialisation par le constructeur. Par exemple, ici une classe Integer(entier, ndt) :

//: C08:EncapsulatingTypes.cpp
#include <iostream>
using namespace std;
 
class Integer {
  int i;
public:
  Integer(int ii = 0);
  void print();
};
 
Integer::Integer(int ii) : i(ii) {}
void Integer::print() { cout << i << ' '; }
 
int main() {
  Integer i[100];
  for(int j = 0; j < 100; j++)
    i[j].print();
} ///:~

Le tableau d' Integer dans main( ) est entièrement initialisé à zéro automatiquement. Cette initialisation n'est pas nécessairement plus coûteuse qu'une boucle for ou que memset( ). Beaucoup de compilateurs l'optimisent très bien.

L'utilisation vue ci-dessus de const est intéressante et probablement utile dans certains cas, mais elle ne résout pas le problème initial qui était : « comment créer une constante de compilation dans une classe ? » La réponse impose l'usage d'un mot-clef supplémentaire qui ne sera pas pleinement introduit avant le Chapitre 10 : static. Ce mot-clef, selon les situations, signifie « une seule instante, indépendamment du nombre d'objets créés », qui est précisément ce dont nous avons besoin ici : un membre d'une classe constant et qui ne peut changer d'un objet de la classe à un autre. Ainsi, un static const d'un type prédéfini peut être traité comme une constante de compilation.

Il y a un aspect de static const, quand on l'utilise dans une classe, qui est un peu inhabituel : vous devez fournir l'initialiseur au point de définition du static const. C'est quelque chose qui ne se produit qu'avec static const; Autant que vous aimeriez le faire dans d'autres situations, cela ne marchera pas, car toutes les autres données membres doivent être initialisées dans le constructeur ou dans d'autres fonctions membres.

Voici un exemple qui montre la création et l'utilisation d'un static const appelé size dans une classe qui représente une pile de pointeurs vers des chaines. (43):

//: C08:StringStack.cpp
// Utilisation de static const pour créer une
// constante de compilation dans une classe
#include <string>
#include <iostream>
using namespace std;
 
class StringStack {
  static const int size = 100;
  const string* stack[size];
  int index;
public:
  StringStack();
  void push(const string* s);
  const string* pop();
};
 
StringStack::StringStack() : index(0) {
  memset(stack, 0, size * sizeof(string*));
}
 
void StringStack::push(const string* s) {
  if(index < size)
    stack[index++] = s;
}
 
const string* StringStack::pop() {
  if(index > 0) {
    const string* rv = stack[--index];
    stack[index] = 0;
    return rv;
  }
  return 0;
}
 
string iceCream[] = {
  "pralines & cream",
  "fudge ripple",
  "jamocha almond fudge",
  "wild mountain blackberry",
  "raspberry sorbet",
  "lemon swirl",
  "rocky road",
  "deep chocolate fudge"
};
 
const int iCsz = 
  sizeof iceCream / sizeof *iceCream;
 
int main() {
  StringStack ss;
  for(int i = 0; i < iCsz; i++)
    ss.push(&iceCream[i]);
  const string* cp;
  while((cp = ss.pop()) != 0)
    cout << *cp << endl;
} ///:~

Comme size est utilisé pour déterminer la taille (size en anglais, ndt) du tableau stack, c'est de fait une constante de compilation, mais une qui est masquée au sein de la classe.

Remarquez que push( ) prend un conststring* comme argument, que pop( ) renvoie un conststring*, et StringStack contient const string*. Si ce n'était pas le cas, vous ne pourriez pas utiliser un StringStack pour contenir les pointeurs dans iceCream. Toutefois, cela vous empêche également de faire quoi que ce soit qui modifierait les objets contenus dans StringStack. Bien sûr, tous les conteneurs ne sont pas conçus avec cette restriction.

Le “enum hack” dans le vieux code

Dans les versions plus anciennes de C++, static const n'était pas supporté au sein des classes. Cela signifiait que const était inutile pour les expressions constantes dans les classes. Toutefois, les gens voulaient toujours le faire si bien qu'une solution typique (généralement dénommée “enum hack”) consistait à utiliser un enum non typé et non instancié. Une énumération doit avoir toutes ses valeurs définies à la compilation, c'est local à la classe, et ses valeurs sont disponibles pour les expressions constantes. Ainsi, vous verrez souvent :

//: C08:EnumHack.cpp
#include <iostream>
using namespace std;
 
class Bunch {
  enum { size = 1000 };
  int i[size];
};
 
int main() {
  cout << "sizeof(Bunch) = " << sizeof(Bunch) 
       << ", sizeof(i[1000]) = " 
       << sizeof(int[1000]) << endl;
} ///:~

L'utilisation de enum ici n'occupera aucune place dans l'objet, et les énumérateurs sont tous évalués à la compilation. Vous pouvez également explicitement établir la valeur des énumérateurs :

enum { one = 1, two = 2, three };

Avec des types enum intégraux, le compilateur continuera de compter à partir de la dernière valeur, si bien que l'énumérateur three recevra la valeur 3.

Dans l'exemple StringStack.cpp ci-dessus, la ligne:

static const int size = 100;

deviendrait :

enum { size = 100 };

Bien que vous verrez souvent la technique enum dans le code ancien, static const a été ajouté au langage pour résoudre précisément ce problème. Cependant, il n'y a pas de raison contraignante qui impose d'utiliser static const plutôt que le hack de enum, et dans ce livre c'est ce dernier qui sera utilisé parce qu'il est supporté par davantage de compilateurs au moment de sa rédaction.

Les fonctions membres d'une classe peuvent être rendues const. Qu'est-ce que cela veut dire ? Pour le comprendre, vous devez d'abord saisir le concept d'objets const.

Un objet const est défini de la même façon pour un type défini par l'utilisateur ou pour un type prédéfini. Par exemple :

const int i = 1;
const blob b(2);

Ici, b est un objet const de type blob. Son constructeur est appelé avec l'argument 2. Pour que le compilateur impose la const ance, il doit s'assurer qu'aucune donnée membre de l'objet n'est changée pendant la durée de vie de l'objet. Il peut facilement garantir qu'aucune donnée publique n'est modifiée, mais comment peut-il savoir quelles fonctions membres modifieront les données et lesquelles sont « sûres » pour un objet const ?

Si vous déclarez une fonction membre const, vous dites au compilateur que la fonction peut être appelée pour un objet const. Une fonction membre qui n'est pas spécifiquement déclarée const est traitée comme une fonction qui modifiera les données membres de l'objet, et le compilateur ne vous permettra pas de l'appeler pour un objet const.

Cela ne s'arrête pas ici, cependant. Dire simplement qu'une fonction membre est const ne garantit pas qu'elle se comportera ainsi, si bien que le compilateur vous force à définir la spécification const quand vous définissez la fonction. (Le const fait partie de la signature de la fonction, si bien que le compilateur comme l'éditeur de liens vérifient la const ance.) Ensuite, il garantit la const ance pendant la définition de la fonction en émettant un message d'erreur si vous essayez de changer un membre de l'objet ou d'appeler une fonction membre non- const. Ainsi on garantit que toute fonction membre que vous déclarez const se comportera de cette façon.

Pour comprendre la syntaxe de déclaration des fonctions membres const, remarquez tout d'abord que placer la déclaration const avant la fonction signifie que la valeur de retour est const: cela ne produit pas l'effet désiré. À la place, vous devez spécifier le const après la liste des arguments. Par exemple :

//: C08:ConstMember.cpp
class X {
  int i;
public:
  X(int ii);
  int f() const;
};
 
X::X(int ii) : i(ii) {}
int X::f() const { return i; }
 
int main() {
  X x1(10);
  const X x2(20);
  x1.f();
  x2.f();
} ///:~

Remarquez que le mot-clef const doit être répété dans la définition ou bien que le compilateur la verra comme une fonction différente. Comme f( ) est une fonction membre const, si elle essaie de modifier i de quelle que façon que ce soit ou d'appeler une autre fonction membre qui ne soit pas const, le compilateur le signale comme une erreur.

Vous pouvez constater qu'une fonction membre const peut être appelée en toute sécurité que les objets soient const ou non. Ainsi, vous pouvez le considérer comme la forme la plus générale de fonction membre (et à cause de cela, il est regrettable que les fonctions membres ne soient pas const par défaut). Toute fonction qui ne modifie pas les données membres devrait être déclarée const, afin qu'elle puisse être utilisée avec des objets const.

Voici un exemple qui compare les fonctions membres const et non const :

//: C08:Quoter.cpp
// Sélection aléatoire de citation
#include <iostream>
#include <cstdlib> // Générateur de nombres aléatoires
#include <ctime> // Comme germe du générateur
using namespace std;
 
class Quoter {
  int lastquote;
public:
  Quoter();
  int lastQuote() const;
  const char* quote();
};
 
Quoter::Quoter(){
  lastquote = -1;
  srand(time(0)); // Germe du générateur de nombres aléatoires
}
 
int Quoter::lastQuote() const {
  return lastquote;
}
 
const char* Quoter::quote() {
  static const char* quotes[] = {
    "Are we having fun yet?",
    "Doctors always know best",
    "Is it ... Atomic?",
    "Fear is obscene",
    "There is no scientific evidence "
    "to support the idea "
    "that life is serious",
    "Things that make us happy, make us wise",
  };
  const int qsize = sizeof quotes/sizeof *quotes;
  int qnum = rand() % qsize;
  while(lastquote >= 0 && qnum == lastquote)
    qnum = rand() % qsize;
  return quotes[lastquote = qnum];
}
 
int main() {
  Quoter q;
  const Quoter cq;
  cq.lastQuote(); // OK
//!  cq.quote(); // Pas OK; fonction pas const
  for(int i = 0; i < 20; i++)
    cout << q.quote() << endl;
} ///:~

Ni les constructeurs ni les destructeurs ne peuvent être const parce qu'ils effectuent pour ainsi dire toujours des modifications dans l'objet pendant l'initialisation et le nettoyage. La fonction membre quote( ) ne peut pas non plus être const parce qu'elle modifie la donnée membre lastquote(cf. l'instruction return). Toutefois, lastQuote( ) ne réalise aucune modification et peut donc être const et peut être appelée par l'objet const cq en toute sécurité.

mutable : const logique vs. const de bit

Que se passe-t-il si vous voulez créer une fonction membre const mais que vous voulez toujours changer certaines données de l'objet ? Ceci est parfois appelé const de bit et constlogique(parfois également constde membre). const de bit signifie que chaque bit dans l'objet est permanent, si bien qu'une image par bit de l'objet ne changera jamais. const logique signifique que, bien que l'objet entier soit conceptuellement constant, il peut y avoir des changements sur une base membre à membre. Toutefois, si l'on dit au compilateur qu'un objet est const, il préservera jalousement cet objet pour garantir une const ance de bit. Pour réaliser la const ance logique, il y a deux façons de modifier une donnée membre depuis une fonction membre const.

La première approche est historique est appelée éviction de la constance par transtypage( casting away constness en anglais, ndt) C'est réalisé de manière relativement bizarre. Vous prenez this(le mot-clef qui donne l'adresse de l'objet courant) et vous le transtypé vers un pointeur vers un objet du type courant. Il semble que this est déjà un pointeur de ce type. Toutefois, dans une fonction membre const c'est en fait un pointeur const. Le transtypage permet de supprimer la const ance pour cette opération. Voici un exemple :

//: C08:Castaway.cpp
//  Constance contournée par transtypage
 
class Y {
  int i;
public:
  Y();
  void f() const;
};
 
Y::Y() { i = 0; }
 
void Y::f() const {
//!  i++; // Erreur -- fonction membre const
  ((Y*)this)->i++; // OK : contourne la constance
  // Mieux : utilise  la syntaxe de transtypage expicite du :
  (const_cast<Y*>(this))->i++;
}
 
int main() {
  const Y yy;
  yy.f(); // Le modifie réellement !
} ///:~

Cette approche fonctionne et vous la verrez utilisée dans le code ancien, mais ce n'est pas la technique préférée. Le problème est que ce manque de const ance est dissimulé dans la définition de la fonction membre, et vous ne pouvez pas savoir grâce à l'interface de la classe que la donnée de l'objet est réellement modifiée à moins que vous n'ayez accès au code source (et vous devez suspecter que la const ance est contournée par transtypage, et chercher cette opération). Pour mettre les choses au clair, vous devriez utiliser le mot-clef mutable dans la déclaration de la classe pour spécifier qu'une donnée membre particulière peut changer dans un objet const :

//: C08:Mutable.cpp
// Le mot-clef "mutable" 
 
class Z {
  int i;
  mutable int j;
public:
  Z();
  void f() const;
};
 
Z::Z() : i(0), j(0) {}
 
void Z::f() const {
//! i++; // Erreur -- fonction membre const
    j++; // OK: mutable
}
 
int main() {
  const Z zz;
  zz.f(); // Le modifie réellement !
} ///:~

Ainsi, l'utilisateur de la classe peut voir par la déclaration quels membres sont susceptibles d'être modifiés dans une fonction membre const.

ROMabilité

Si un objet est défini const, c'est un candidat pour être placé dans la mémoire morte (ROM = Read Only Memory, ndt), ce qui est souvent une question importante dans la programmation des systèmes embarqués. Le simple fait de rendre un objet const, toutefois, ne suffit pas - les conditions nécessaires pour la ROMabilité sont bien plus strictes. Bien sûr, l'objet doit avoir la const ance de bit, plutôt que logique. Ceci est facile à voir si la const ance logique est implémentée uniquement par le mot-clef mutable, mais probablement indétectable par le compilateur si la const ance est contournée par transtypage dans une fonction membre const. En outre,

1. La class e ou la struct ure ne doivent pas avoir de constructeur ou de destructeur définis par l'utilisateur.
2. Il ne peut pas y avoir de classe de base (cf. Chapitre 14) ou d'objet membre avec un constructeur ou un destructeur défini par l'utilisateur.

L'effet d'une opération d'écriture sur toute partie d'un objet const de type ROMable est indéfini. Bien qu'un objet correctement conçu puisse être placé dans la ROM, aucun objet n'est jamais obligé d'être placé dans la ROM.