Comprendre les constantes

Les constantes sont méconnues et incomprises de plusieurs informaticien(ne)s. Pourtant, il s'agit d'un élément important et précieux de la boîte à outils des programmeuses et des programmeurs.

Décrit simplement, une constante est un objet dont l'état ne peut plus changer une fois son caractère constante spécifié. La portée de cet énoncé varie d'un langage à l'autre :

• Dans les langages .NET, seuls les données dont le type est primitif peuvent être spécifiés constantes, et ce dès leur déclaration
• En Java, les données de types primitifs peuvent être spécifiés constantes, comme dans les langages .NET. Il est aussi possible de spécifier une référence comme étant constante, mais il est impossible de spécifier un référé comme étant constant (cela dit, il existe des techniques pour spécifier manuellement la constance par création de classes dites immuables)
• En Java comme dans les langages .NET, il est aussi possible de spécifier une classe comme étant non spécialisable, ce qui constitue un cas particulier de constance au sens d'un design hiérarchique (le mot clé final apposé à une classe en Java sert à cette fin, tout comme les mots clés sealed en C# et NotInheritable en VB.NET). C++ permet de réaliser des stratégies semblables avec des qualifications d'héritage et de constructeurs autres que la qualificiation public mais le recours à cette façon de faire est rattachée de près à certains langages et est moins utile en C++
• Le langage C++ offre une gamme importante de lieux où la qualification de constance prend son sens. C'est l'une de ses forces, mais elle est méconnue

Cet article se veut un bref résumé du rôle des constantes dans un programme. J'utiliserai C++ comme référence parce qu'il permet de couvrir (beaucoup) plus de cas que la plupart des autres langages (C, Java, les langages .NET, etc.).

Constantes connues à la compilation

Une première catégorie, classique et supportée par la plupart des langages de programmation (du moins dans le cas des types primitifs), est celle des constantes dont la valeur est connue à la compilation.

#include "Note.h"
#include <string>
const int NELEVES = 30;
const float PI = 3.14159f;
const std::string NOM_DEFAUT = "Joe Blo";
const Note SEUIL_PASSAGE = Note(60);

Les constantes connues à la compilation :

• Clarifient le programme en donnant un sens aux énoncés et en l'autodocumentant
• Simplifient son entretien, même à court terme
• Ne coûtent rien à l'exécution, que ce soit en temps ou en espace

Évidemment, la conséquence de marquer un objet comme étant constant est que le programme s'engage à ne pas en modifier l'état par la suite.

Constantes non primitives

Notez que, dans les exemples de déclarations de constantes plus haut, celles qui sont de types non primitifs (SEUIL_PASSAGE et NOM_DEFAUT) sont des objets constants. En tant que tels, ils doivent être construits et ils doivent être détruits.

Un objet constant est considéré constant suite à sa construction et jusqu'au début de sa destruction. Pendant la construction de l'objet (donc pendant son initialisation), il est évidemment possible de le modifier, sinon il n'y aurait pas d'objet. De même, pendant sa destruction, il est possible de le modifier sinon l'objet ne pourrait pas libérer les ressources qu'il s'est attribué pendant son existence.

La règle de constance sur un objet constant est qu'on ne peut ni modifier ses attributs, ni invoquer sur lui une méthode qui n'en garantisse pas la constance. Nous y reviendrons plus bas.

Constantes et valeurs dépendantes

const int MENU_QUITTER = 0;
const int MENU_AVANCER = 1;
const int MENU_RECULER = 2;

Maintenant, imaginons que l'on veuille plus de souplesse, par exemple parce qu'on estime important de pouvoir commencer les options de menu à 1 plutôt qu'à 0.

enum {
   MENU_BASE, MENU_QUITTER, MENU_AVANCER, MENU_RECULER
};

const int MENU_BASE = 0;
const int MENU_QUITTER = MENU_BASE + 0;
const int MENU_AVANCER = MENU_BASE + 1;
const int MENU_RECULER = MENU_BASE + 2;

Constantes connues à la compilation, locales et automatiques

#include <iostream>
template <int N>
bool lire(int (&tab)[N]) {
   using namespace std;
   for (int i = 0; i < N; ++i) {
      cout << "Element " << i + 1 << ": ";
      if (!(cin >> elems[i]))
         return false; // erreur de lecture
   }
   return true; // tout a été bien lu
}
template <int N>
void afficher_inverse(const int (&tab)[N]) {
   for (int i = N - 1; i >= 0; --i)
      cout << elems[i] << ' ';
   cout << endl;
}
int main() {
   const int NELEMS = 10;
   int elems[NELEMS];
   if (lire(elems))
      afficher_inverse(elems);
}

Constantes connues à la compilation, locales et statiques

Avec les objets, une petite nuance s'impose.

#include <iostream>
#include <string>
void identifier_generique() {
   using namespace std;
   const string NOM_GENERIQUE = "Joe Blo";
   if (string nom; cin >> nom && nom == NOM_GENERIQUE)
      cout << "Vous êtes bien générique, il me semble..."
           << endl;
}

Si le compilateur décidait de ne pas construire puis détruire NOM_GENERIQUE à chaque appel de identifier_generique(), cette décision pourrait nuire au bon fonctionnement du programme.

#include <iostream>
#include <string>
void identifier_generique() {
   using namespace std;
   static const string NOM_GENERIQUE = "Joe Blo";
   if (string nom; cin >> nom && nom == NOM_GENERIQUE)
      cout << "Vous êtes bien générique, il me semble..."
           << endl;
}

On obtient ainsi le meilleur des mondes :

• La constante NOM_GENERIQUE n'est initialisée qu'une seule fois (et n'est détruite qu'une seule fois)
• Sa constance est garantie par le compilateur (toute tentative de s'en servir d'une manière contrevenant à sa constance générera une erreur de compilation)
• Le code demeure clair et symbolique
• Il n'y a aucun coût associé en temps ou en espace (en fait, ici, le recours à une constante résultera généralement en du code plus rapide que le recours à un littéral... Voyez-vous pourquoi?)

Constantes entières connues à la compilation et tableaux

float tabA[10]; // Ok mais ouache
const int N = 10;
float tabB[N]; // Ok
int n;
cin >> n;
const int SURPRISE = n;
// illégal: SURPRISE n'est pas
// connue à la compilation
float tabC[SURPRISE];

Nous reviendrons un peu plus loin sur le recours à un nom en majuscules dans un tel cas qui est un peu abusif.

Le cas des constantes de classe

En POO, il est possible de définir des constantes de classes. Ceci permet de regrouper ensembles une idée, par exemple celle de cours, et les idées associées, par exemple le nombre d'élèves et un tableau d'élèves.

// ...
class Personne {
   static const inline std::string NOM_DEFAUT = "Joe Blo";
};
// ...

#ifndef PERSONNE_H
#define PERSONNE_H
//
// Personne.h
//
#include <string>
class Personne {
   static const std::string NOM_DEFAUT;
   // ...
};
#endif

#include "Personne.h"
#include <string>
using std::string;
//
// Personne.cpp
//
const string Personne::NOM_DEFAUT = "Joe Blo";

Pensez-y :

• Le fichier A.cpp inclut Personne.h, puis
• Le fichier B.cpp inclut Personne.h, et
• Les deux fichiers résultant (A.obj et B.obj, disons) sont liés pour créer un chic exécutable

Lequel d'entre A.obj et B.obj devrait contenir la définition de la constante Personne::NOM_DEFAUT? La réponse est qu'aucun n'est plus qualifié que l'autre en ce sens, or si cette constante était définie dans Personne.h, alors A.cpp et B.cpp seraient tous deux aussi conscients des règles s'appliquant à sa contruction.

En pratique, on déclare donc les attributs de classe (ceux qualifiés static) dans la déclaration d'une classe (le .h dans la plupart des cas) et on les définit dans un fichier source (.cpp) associé à la classe. Le cas ci-dessus devient donc :

• Le fichier A.cpp inclut Personne.h
• Le fichier B.cpp inclut Personne.h, et
• Le fichier Personne.cpp inclut Personne.h et définit Personne::NOM_DEFAUT
• Les trois fichiers résultant sont liés pour créer un chic exécutable et une seule définition exiuste alors pour la constante Personne::NOM_DEFAUT. Problème réglé

Ceci nous mène au cas des attributs d'instances qui sont des tableaux. Comme toujours, certaines contraintes s'appliquent :

#ifndef COURS_H
#define COURS_H
//
// Cours.h
//
#include "Eleve.h"
class Cours {
   static const int NELEVES;
   // illégal: valeur de NELEVES inconnue ici
   Eleve eleves[NELEVES];
   // ...
};
#endif

#include "Cours.h"
//
// Cours.cpp
//
const int Cours::NELEVES = 30;

Pour cette raison, plusieurs compilateurs acceptent une dispense particulière pour les constantes de classe entières (et seulement elles; cette dispense ne s'applique pas aux autres types, même primitifs) qui peuvent être définies à même la déclaration de la classe.

//
// Cours.h
//
#include "Eleve.h"
class Cours {
   static const int NELEVES = 30;
   Eleve eleves[NELEVES];
   // ...
};

Ainsi, dans la classe Cours proposée à droite, on aurait pu remplacer la définition static const int NELEVES = 30; par la définition enum { NELEVES = 30 }; pour obtenir exactement le même résultat. On pourrait d'ailleurs toujours procéder ainsi dans le cas des constantes entières, ce que certains (dont moi) font régulièrement parce que la formule résultante est plus succincte et plus compacte.

Il n'y a aucun avantage à l'une des formules en comparaison avec l'autre dans les cas des entiers. Le résultat est strictement équivalent en taille ou en vitesse ou en lisibilité (les symboles sont les mêmes dans le code et se nomment dans chaque cas de la même manière, soit Cours::NELEVES dans notre exemple). La préférence pour l'une ou l'autre de ces formes est d'ordre esthétique.

Les majuscules et le sens des constantes

Vous aurez remarqué que les constantes utilisées jusqu'ici dans cet article ont toutes des noms écrits en majuscules.

Ce choix est volontaire et respecte la tradition. La plupart des constantes système de C et de C++ sont écrites en minuscules, et utiliser dans nos progammes des noms en majuscules réduit les risques de conflits. De même, les constantes sont des indicateurs importants dans un programme et les rendre visibles est une bonne chose.

Vous remarquerez aussi que je n'appliquerai plus cette politique de manière systématique plus bas. La raison est que nous allons opérer un glissement sémantique en passant de constantes dont la valeur est connue à la compilation à des constantes dont la valeur est fixée à l'exécution.

Les deux catégories de constantes partagent une caractéristique fonamentale : elles ne peuvent changer d'état une fois qualifiées constantes. Elles ne partagent toutefois pas la caractéristique d'être connues lorsque le programme est compilé, et ne peuvent pas jouer le même rôle dans un programme.

Par exemple, pour déclarer un tableau de manière automatique dans un sous-programme (en tant que variable locale), le compilateur doit connaître la taille du tableau à la compilation pour lui réserver un espace suffisant. Une constante entière dont la valeur est connue à la compilation permet cela; une constante entière dont la valeur n'est pas connue à la compilation ne le permet pas (par définition).

J'utiliserai donc les majuscules pour les constantes statiques, dont la valeur est fixée dès la compilation d'un programme, mais pas pour les constantes dynamiques, dont la valeur initiale dépend de l'exécution du programme mais demeure fixée à partir de sa déclaration.

Constantes d'instances

Moins connues que les constantes de classes mais parfois fort sympathiques : les constantes d'instances. La différence entre les deux va comme suit :

• Une constante de classe est partagée par toutes les instances de cette classe. En C++ et en Java, elle est qualifiée static const (en Java, static final; en C#, const tout simplement car les constantes d'instances ny sont pas supportées)
• Une constante d'instance est constante pour la vie d'une instance et appartient à cette instance. Chaque instance d'une même classe en possédera sa propre version et la valeur de cette constante pour une instance donnée pourra être différente de celle des autres instances. En C++, on parle d'attributs const sans être static et, en Java, d'attributs final sans être static

class ValeurFixe {
   const int val;
public:
   ValeurFixe() : val{} {
   }
   ValeurFixe(int valeur) : val{valeur} {
   }
   // Sainte-Trinité implicitement correcte
   int valeur() const {
      return val;
   }
   // ...
};

En Java, une constante d'instance doit avoir une valeur fixée (une seule fois!) à l'intérieur du constructeur de l'instance à laquelle elle appartient, mais il n'existe pas de mécanique spécifique pour la préconstruire.

Remarquez qu'utiliser une constante d'instance restreint certaines opérations sur l'objet qui la possède. Entre autres, il est imposible de modifier cet état de l'objet, ce qui implique que l'opérateur d'affectation par défaut, généré par le compilateur si la programmeuse ou le programmeur n'en a pas suppléé(e) une lui-même ou elle-même, ne sera pas opérationnel puisque, par défaut, il cherche à réaliser une affectation membre à membre des attributs, chose illégale par définition sur un membre constant.

Constantes locales connues à l'exécution

Il peut arriver qu'un sous-programme utilise une constante locale qui soit fixée pour la duré de l'invocation du sous-programme mais qui ne soit pas connue à la compilation, par exemple dans le cas où elle dépendrait de la valeur d'un paramètre.

#include <cmath>
bool est_premier(int n) {
   using std::sqrt;
   // les cas à traiter sont 2 et les impairs alant
   //  inclusivement de 3 à la racine carrée de n
   const int SEUIL = sqrt(n);
   // ... reste du code ...
}

Pour plusieurs raisons :

• D'abord, à des fins de documentation. Ici, le seuil jusqu'auquel nous ferons des calculs est effectivement constant pour la durée de l'invocation de la fonction. Ce souci documentaire explique le choix esthétique d'une écriture en majuscules (bien que SEUIL ne pourrait pas ici servir de taille pour un tableau créé automatiquement) et un nom comme Seuil aurait aussi pu être approprié ici (cependant, soyez conséquentes et conséquents dans vos choix à l'intérieur d'un même programme)
• Ensuite, à des fins de performance. Un compilateur peut (même si certaine ne le font pas) considérer le caractère constant d'une donnée comme un signal qu'il peut réaliser certaines optimisations agressives, par exemple laisser la valeur de cette constante dans un registre sans la recharger chaque fois que le besoin s'en fait sentir puisque la constance de sa valeur est garantie par le processus de compilation
• Enfin, à titre de protection, pour éviter qu'une programmeuse ou qu'un programmeur imprudent(e) ne modifie accidentellement une donnée qui n'est pas prévue en ce sens, donc pour laquelle l'algorithme présume une constance. Des accidents se produisent dans la rédaction et dans l'entretien d'une chose aussi complexe qu'un programme et nous avons le privilège de disposer d'outils nous permettant de les garder en nombre limité

Paramètres constants

Il est aussi possible d'utiliser des paamètres constants. Un trouve trois catégories de tels paramètres, soit les paramètres constants par valeur, les paramètres constants par référence et les paramètres constants par adresse.

Vous remarquerez que les noms des paramètres constants ne sont habituellement pas écrits strictement en majuscules, respectant plutôt les usages habituels pour les noms de variables. L'idée derrière cette façon de faire est que les paramètres constants sont surtout des objets sur lesquels le progamme, pour une courte période (la durée du sous-programme), s'engage à ne pas modifier quelque état que ce soit.

Le compilateur garantit le respect de cet engagement en refusant de compiler le sous-programme si le contrat n'est pas respecté. De même, le compilateur peut profiter de cet engagement pour procéder à un certain nombre d'optimisations agressives; en toute honnêteté, cela dit, la plupart n'en profitent pas.

Paramètres par valeur constants

Les paramètres par valeur constants jouent le même rôle que les constantes locales connues à l'exécution : ce sont des indications au compilateur que la valeur d'un paramètre ne sera pas modifiée lors de l'exécution d'un sous-programme.

#include <ostream>
void afficher_valeurs(std::ostream &os, int min, const int max) {
   for(; min <= max; ++min)
      os << min << ' ';
   os.flush();
}

Paramètres par référence-vers-const

Une donnée d'un type primitif est habituellement de petite taille et peut être copiée sans coût réel lorsqu'on la passe en paramètre à un sous-programme. En retour, copier un objet est une opération de complexité arbitrairement grande puisque l'action de copier un objet implique un appel de sous-programme (son contructeur de copie) pour créer la temporaire résultante et un autre appel de sous-programme (son destructeur) pour l'éliminer.

class X {
   // ...
};
//
// sans danger, mais implique créer et
// détruire un X temporaire
//
void f0(X);
// rapide mais met le X original à risque
void f1(X&);
//
// rapide et sans danger. Règle générale,
// mieux que f0() si la fonction ne fait
// pas de copie locale du paramètre
//
void f2(const X&);

En retour, f2() combine sécurité et rapidité : son paramètre est une référence sur un X const, ce qui signifie que le X original ne sera pas copié à l'invocation de f2() (le paramètre étant une référence) et que le X original ne risquera pas d'être modifié par l'exécution de f2() (la référence étant constante).

C'est pourquoi, si un sous-programme ne compte pas modifier une donnée dont le type n'est pas primitif, il est pratiquement toujours préférable de la passer par référence constante plutôt que de la passer par valeur. Évidemment, si un sous-programme compte modifier la donnée, la passer par référence tout court reste la chose à faire.

//
// sans danger; crée un double temporaire
//
void g0(double);
//
// permet à g1() de modifier le double original
//
void g1(double&);
//
// équivalent à g0(); un bon compilateur pourra
// mieux faire avec g2() qu'avec g0(), mais ces
// compilateurs sont rares
//
void g2(const double);
//
// avec un type primitif, g3() est souvent moins
// efficace que g2(). Cela dit, faut tester!
//
void g3(const double&);

Autre petite parenthèse : bien que passer un objet en paramètre par référence-vers-const soit habituellement plus efficace que de le passer par valeur, les deux options restent possibles. Le système de types de C++ demeure très homogène.

Paramètres par adresse constants

Les paramètres par adresse constants existent à la fois en C et en C++. L'idée d'un paramètre par adresse constant est de permettre de manipuler une indirection tout en offrant une garantie de non-modification.

// version compacte et traditionnelle
char *strcpy(char *dest, const char *src) {
   for (; *dest++ = *src++; )
      ;
   return dest;
}
// si vous préférez quelque chose de plus convivial
char *strcpy_gentil(char *dest, const char *src) {
   char *p = dest;
   while (*src != '\0') {
      *p = *src;
      ++p;
      ++src;
   };
   *p= '\0';
   return dest;
}

En examinant l'une ou l'autre des formes de cette fonction, on remarquera effectivement que *dest (là où pointe dest) se fait affecter des valeurs alors que *src (là où pointe src) ne sert qu'en lecture (à droite des affectations). En fait, on utilise un pointeur temporaire (non constant) nommé p pour itérer à partir de dest parce que la convention est que strcpy() retourne l'adresse de destination suite à la copie des données.

Remarquez que la protection offerte par une adresse constante est limitée : ici, si src et dest se chevauchent, écrire dans *dest risque de modifier la zone où mène src. Cela fait partie des risques de code reposant sur des pointeurs, jouet puissant mais dangereux s'il en est un.

Remarquez aussi qu'incrémenter un pointeur vers une donnée constante n'est pas illégal puisque cela déplace le pointeur sans changer la valeur du pointé. Il est toutefois possible, en déplaçant le mot const, de spécifier p est un pointeur constant vers une donnée (p. ex. : char * const p) ou de spécifier p est un pointeur constant vers une donnée constante (p. ex. : const char * const p), mais la forme p est un pointeur vers une donnée constante (p. ex. : const char *p) est la plus fréquente et la plus utile en général.

Méthodes const

class entier {
   int val = 0;;
public:
   entier() = default;
   entier(int val) : val{ val } {
   }
   //
   // Ok: méthode qualifiée const, laisse
   // l'instance intacte
   //
   int valeur() const {
      return val;
   }
   entier operator-() const {
      return { -valeur() };
   }
   void inverser() { // ne peut être const
      val = -val;
   }
   bool operator==(const entier &autre) const {
      return valeur() == autre.valeur();
   }
   // ...
};

En retour, plusieurs méthodes sont typiquement const :

• Les accesseurs (méthodes get) sont souvent const
• Les opérateurs relationnels (==, !=, <, <=, >, >=) et les opérateurs logiques (&&, ||, !) sont presque const s'ils sont déclarés en tant que méthodes d'instances plutôt qu'en tant que fonctions globales
• Les opérateurs artihmétiques à deux opérandes (+, -, *, /, %) sont souvent const s'ils sont déclarés en tant que méthodes d'instances plutôt qu'en tant que fonctions globales
• Les opérateurs de conversion (p. ex. : operator int()) sont typiquement const
• Les méthodes de consultation ou d'utilisation (dessiner(), surface(), est_plein(), ce genre de truc) sont souvent const; etc.

#include <iostream>
template <int N>
   class Tableau {
      int vals[N]{};
   public:
      Tableau() = default;
      int& operator[](int n) { // pas const
         return vals[n];
      }
      int operator[](int n) const {
         return vals[n];
      }
   };
template &int N>
   void remplir(Tableau<N> tab, int val) {
      for(int i = 0; i ! N; ++i)
         tab[i] = val; // version non-const (tab est non-const)
   }
template &int N>
   void afficher(const Tableau<N> tab, int val) {
      for(int i = 0; i ! N; ++i)
         std::cout << tab[i] << ' '; // version const (tab est const)
   }

Les méthodes const sont nécessaires à un système de types homogène si celui-ci admet des objets. Sur un objet const, seules les méthodes const peuvent être utilisées. Ainsi, si la programmeuse ou le programmeur d'une classe donnée néglige de qualifier const les méthodes qui devraient l'être, alors il devient impossible de manipuler une instance constante de cette classe. Le code devient inefficace ou tout simplement inutilisable.

La position du mot const dans une signature de méthode ou de fonction est importante. Dans l'exemple ci-dessous (où le type interne et public str_type, correspondant à std::string, est défini pour alléger l'écriture) :

#include <string>
class Professeur {
public:
   using str_type = std::string;
private:
   str_type nom_;
public:
   // ...
   //
   // La méthode nom() retourne un const str_type&
   // pour donner un exemple; en pratique, je vous
   // recommande de retourner une copie (donc un
   // str_type tout simplement)
   //
   const str_type &nom() const {
      return nom_;
   }
   str_type titre() const {
      static const str_type PREFIXE = "Professeur ";
      return PREFIXE + nom();
   }
   Professeur(const str_type &nom) : nom_{ nom } {
   }
   bool operator==(const Professeur &p) const {
      return nom() == p.nom();
   }
   bool operator!=(const Professeur &p) const {
      return !(*this == p);
   }
   //
   // ...
   //
};