Sérialiser

Imaginons le problème suivant : dans un système où on trouve des instances de la classe Bonhomme, représenter un Bonhomme sous forme sérialisée et construire un Bonhomme à partir de sa forme sérialisée.

Nous devrons respecter une contrainte stricte : la forme sérialisée devra en bout de ligne reposer strictement sur des représentations primitives, de telle sorte qu'elle puisse être projetée sur une séquence de bytes et récupérée par un outil écrit dans un autre langage de programmation quel qu'il soit.

Évidemment, sérialiser un Bonhomme est une description trop large du mandat qui nous attend; il nous faut tout d'abord décrire ce qu'est un Bonhomme. Dans le cas qui nous intéresse, une description de ce qu'est un Bonhomme en vaut bien une autre.

// ...
#include <string>
// using...
struct Vecteur3D {
   float x, y, z;
   Vecteur3D() : x{}, y{}, z{} {
   }
   Vecteur3D(float x, float y, float z) :x{z}, y{z}, z{z} {
   }
   // autres méthodes
};
class Bonhomme {
public:
   using vie_t = short;
private:
   string nom_;
   vie_t vie_;
   Vecteur3D position_,
             direction_;
   // méthodes
};
// ...

Sérialisation brute : à éviter

template <class T>
   void serialiser(const T &val, ostream &os) {
      const char *p= reinterpret_cast<const char*>(&val);
      copy(p, p+sizeof(T), ostreambuf_iterator<char>(os));
   }

template <class T>
   istream& deserialiser(T &val, istream &is) {
      char *p = reinterpret_cast<char *>(&val);
      for (size_t i = 0; i < sizeof(T) && is.get(*(p+i)); ++i)
         ;
      return is;
   }

Cette époque était celle où les POD constituaient l'essentiel des types de données manipulés par les programmes. Nous devons mettre de l'avant à quel point ces deux exemples sont dangereux dans des programmes contemporains. En effet :

template <class T>
   union EntiteBrute {
      T objet_;
      char alignas(T) bytes_[sizeof(T)]; 
   };

• Ils ne tiennent pas compte de la présence d'éléments indirects (pointeurs, références) dans une instance de T
• Ils présument que la forme binaire des membres sera identique entre le sérialisant et le désérialisant (même technologie d'ordinateur, même structure binaire avant sérialisation et après désérialisation), et
• Ils constituent un grave bris d'encapsulation

Règle générale, il n'est pas possible de compter sur une forme d'organisation binaire spécifique pour une instance d'un classe donnée.

Nous ne voulons pas savoir avec précision comment un objet est structuré[1], et cela s'applique récursivement aux objets construits par composition ou par héritage, qu'il soit simple ou multiple[2].

Au contraire, nous souhaitons que l'opération de sérialisation soit subjective, donc que chaque objet soit tenu pour responsable de sa propre autodescription.

Dans la mesure où le format de l'objet une fois sérialisé est connu et documenté, la désérialisation pourra se faire par divers moyens et l'objet reconstitué pourra être tenu pour structurellement équivalent à l'original, mais pas nécessairement identique[3].

Version simple de la sérialisation

Évidemment, sérialiser un Bonhomme est une description trop large du mandat qui nous attend; il nous faut tout d'abord décrire ce qu'est un Bonhomme.

#include <string>
#include <fstream>
// using...
Bonhomme test_serialisation(const Bonhomme &b, const string &fich) {
   {
      ofstream os(fich);
      os << b;
   }
   Bonhomme b2;
   ifstream is(fich);
   is >> b2; // tester pour les erreurs
             // (omis pour économie)
   return b2;
}

// Vecteur3D.cpp
#include "Vecteur3D.h"
#include <istream>
#include <ostream>
// using ...
ostream& operator<<(ostream &os, const Vecteur3D &v) {
   return os << v.x << v.y << v.z;
}
istream& operator>>(istream &is, Vecteur3D &v) {
   if (!is) return is;
   return is >> v.x >> v.y >> v.z;
}

// Bonhomme.cpp
#include "Bonhomme.h"
#include <iostream>
#include <string>
// using ...
ostream& operator<<(ostream &os, const Bonhomme &b) {
   return os << b.nom() << b.vie()
             << b.position()
             << b.direction();
}
istream& operator>>(istream &is, Bonhomme &b) {
   if (!is) return is;
   string nom;
   Bonhomme::vie_t vie;
   Vecteur3D pos, dir;
   if (is >> nom >> vie >> pos >> dir)
      b = Bonhomme{nom, vie, pos, dir};
   return is;
}

Tout d'abord, écrivons un petit programme de test qui soit semblable en forme à la fonction test_serialisation() proposée plus haut :

#include "Bonhomme.h"
#include <fstream>
#include <iostream>
#include <string>
int main() {
   // using ...
   const string fich = "Test.dat";
   {
      Bonhomme b("Fred", 50, Vecteur3D(5, 5, 5)); // direction par défaut
      cout << b;
      ofstream ofs{fich};
      ofs << b;
   }
   Bonhomme b;
   ifstream ifs{fich};
   if (ifs >> b)
      cout << b << endl;
   else
      cerr << "Incapable de consommer le Bonhomme!" << endl;
}

Ce programme crée un Bonhomme du nom de "Fred" ayant 50 points de vie, une position initiale de {5,5,5} et une direction initiale par défaut. On présume ici que Bonhomme expose un constructeur paramétrique pour lequel le compilateur peut remplacer les paramètres par des valeurs par défaut.

Si notre travail a été bien réalisé, alors les deux opérations d'écriture à la console (soit celle faite avec le Bonhomme original et celle faite avec le Bonhomme suivant la désérialisation) devraient donner exactement le même résultat, la version désérialisée étant présumée copie conforme de la version originale.

Le problème survient du fait que nous n'avons pas inséré de délimiteurs (des caractères d'espacement, dans ce cas-ci, puisque nous passons par un format intermédiaire sous forme de texte) entre les états lors de la sérialisation.

Ainsi, notre Bonhomme, une fois sérialisé, aura la forme "Fred50555100" (présumant que la direction par défaut soit {1,0,0}). Lors de la désérialisation, le tout apparaîtra comme une chaîne de caractères valide, et sera consommé par l'extraction du nom du Bonhomme à partir du flux en entrée.

// ...
ostream& operator<<(ostream &os, const Vecteur3D &v) {
   return os << v.x << ' ' << v.y << ' ' << v.z;
}
istream& operator>>(istream &is, Vecteur3D &v) {
   if (!is) return is;
   float x, y, z;
   if (is >> x >> y >> z)
      v = Vecteur3D{x,y,z};
   return is;
}

// ...
ostream& operator<<(ostream &os, const Bonhomme &b) {
   return os << b.nom() << ' ' << b.vie() << ' '
             << b.position() << ' ' << b.direction();
}
istream& operator>>(istream &is, Bonhomme &b) {
   if (!is) return is;
   string nom;
   Bonhomme::vie_t vie;
   Vecteur3D pos, dir;
   if (is >> nom >> vie >> pos >> dir)
      b = Bonhomme{nom, vie, pos, dir};
   return is;
}

Tout va donc pour le mieux dans le meilleur des mondes? Malheureusement, non.

Le problème des chaînes de caractères

Modifions très légèrement le programme de test proposé plus haut, et introduisons un nom un peu plus problématique.

#include "Bonhomme.h"
#include <fstream>
#include <iostream>
#include <string>
int main() {
   // using ...
   const string fich = "Test.dat";
   {
      Bonhomme b{"Fred Emile", 50, Vecteur3D{5, 5, 5}}; // direction par défaut
      cout << b;
      ofstream ofs{fich};
      ofs << b;
   }
   Bonhomme b;
   ifstream ifs{fich};
   if (ifs >> b)
      cout << b << endl;
   else
      cerr << "Incapable de consommer le Bonhomme!" << endl;
}

Ici, l'écriture sur un flux ne pose pas de problème. Le premier cout << b; écrira bel et bien "Fred Emile 50 5 5 5 1 0 0" tel qu'attendu. De même, l'écriture dans le fichier projettera exactement la même forme de texte que l'écriture à la console.

Lors de l'extraction du flux, par contre, nous frapperons un os : l'opération d'extraction d'une chaîne de caractères lit du point d'extraction courant jusqu'au premier caractère d'espacement. Ainsi, ifs >> b; ne lira que Fred comme nom, et le reste de la lecture échouera lamentablement (sur mon poste, la projection à la console du Bonhomme désérialisé donne "Fred -13108 0 0 0 0 0 0" ce qui n'est visiblement pas le résultat souhaité).

Il nous faut donc utiliser une forme de projection du texte sur un flux qui ne soit pas ambiguë et qui permette une désérialisation dont le fruit sera conforme à l'objet avant sérialisation. Quelles sont les options qui s'offrent à nous? Il y en a plusieurs.

Remarque sur l'application des exemples qui suivent

Dans chaque cas en exemple ci-dessous, nous examinerons une paire de fonctions capables de transformer une chaîne standard selon une stratégie symétrique de sérialisation/ désérialisation.

ostream& operator<<(ostream &os, const Bonhomme &b) {
   serialiser(os, b.nom());
   return os << ' ' << b.vie() << ' '
             << b.position() << ' '
             << b.direction();
}
istream& operator>>(istream &is, Bonhomme &b) {
   if (!is) return is;
   string nom;
   Bonhomme::vie_t vie;
   Vecteur3D pos, dir;
   if (deserialiser(is, nom) &&
       is >> vie >> pos >> dir)
      b = Bonhomme{ nom, vie, pos, dir };
   return is;
}

Préfixer le texte de sa taille

// inclusions... using...
ostream& serialiser(ostream &os, const string &s) {
   return os << s.size() << ' ' << s;
}
istream& deserialiser(istream &is, string &s) {
   if (!is) return is;
   string::size_type n;
   if (!(is >> n)) return is;
   char c;
   is.get(c); // consommer le blanc initial
   s.clear();
   for (string::size_type i = 0; i < n && is.get(c); ++i)
      s+= c;
   return is;
}

Un irritant : projeter une chaîne de caractères à la console sous cette forme fait en sorte, du moins par défaut, d'afficher sa taille en tant que préfixe. On a vu plus élégant.

Baliser le texte

Il serait possible de baliser le texte. Ceci pourrait se faire en l'enrobant d'une paire de symboles identiques (disons '\"' avant et après la séquence), ou à tout le moins reconnaissables en tant que marqueurs de début et de fin de chaîne (par exemple <texte> et </texte> pour suivre la mode XML).

Dans les deux cas, la difficulté est la même, soit celle d'éviter la pollution du texte par l'insertion des balises à l'intérieur de la séquence. Par exemple, si nous avons choisi de délimiter le texte par des guillemets et si notre intention est de sérialiser le texte "J'ai dit "Bonjour!"", alors il importe de trouver un mécanisme permettant de distinguer les guillemets balisant la chaîne et ceux qui s'inscrivent dans la séquence de texte en soi.

Pour régler ce problème, il est possible de remplacer le texte irritant par une autre séquence (par exemple, remplacer " par \" lors de la sérialisation et remplacer \" par " lors de la désérialisation, ou remplacer " par &quot; comme on le fait avec HTML). Il faut être prudent car cela demande un schème capable de gérer les remplacements correctement (si le texte \" devait être sérialisé, alors il faudrait trouver un moyen de le représenter en tant que tel, peut-être par \\\"). Notez que ce remplacement symétrique avant projection et après extraction peut coûter cher en temps processeur.

ostream& serialiser(ostream &os, const string &s) {
   return os << '\"' << s << '\"';
}
istream& deserialiser(istream &is, string &s) {
   if (!is) return is;
   char c;
   if (is.get(c) && c != '\"') {
      is.putback(c);
      // mettre is en état d'erreur
      return is;
   }
   string temp;
   while(is.get(c) && c != '\"')
      temp += c;
   if (is) // ou if ( == '\"') au choix
      s = temp;
   return is;
}

Il est aussi possible de réaliser une recherche dans le texte à sérialiser et trouver un symbole, quel qu'il soit, qui n'y apparaît pas, puis s'en servir pour baliser le début et la fin de la séquence. Ce schème fonctionne étonnamment bien pour le texte puisqu'il existe plusieurs caractères non affichables qui risquent très peu d'apparaître dans un flux de texte. L'extraction du texte d'un flux est très rapide (le premier caractère est consommé, puis le texte est consommé jusqu'à ce que la fin du flux soit rencontrée ou jusqu'à ce que ce symbole réapparaisse dans le flux). Par contre, chaque projection nécessite une analyse du texte à projeter, ce qui rend ce schème prohibitif pour les systèmes dynamiques (c'est très bien pour les systèmes où le texte est connu à la compilation ou ceux où le texte est préparé d'avance et provient d'un média).

Enfin, il est possible de faire comme dans une séquence ASCIIZ et de baliser le texte à la fin seulement par un caractère non affichable, typiquement la valeur 0 encodée sur la taille d'un caractère, donc '\0' ou L'\0' selon les standards char et wchar_t mais d'autres symboles peu fréquents dans un texte sont possibles. Cette pratique a l'impact pervers de rendre la projection sur un flux plus difficile à lire (le caractère non affichable corrompt la séquence de texte brut).

Éliminer les blancs

Autre solution, enfin: remplacer bêtement chaque blanc par autre chose et faire une lecture et une écriture simple avec les opérateurs >> et << sur les flux. Les mêmes irritant que ceux mentionnés précédemment s'appliquent (gérer les cas où les symboles utilisés comme remplacement pour les blancs apparaissaient dans le flux original, s'assurer de couvrir tous les cas de blancs possibles, un affichage à la console qui n'est pas harmonieux, etc.).

Variantes

On trouve évidemment des variantes à tous ces schèmes, comme par exemple terminer le texte par une nouvelle ligne et le consommer avec std::getline() (mais que faire quand le texte contient un symbole de changement de ligne?) ou baliser le texte par des guillemets et remplacer les guillemets dans le texte par des double guillemets (donc une séquence de texte ne peut se terminer par un nombre pair de guillemets) comme en langage Pascal.

Aucun de ces schèmes n'est parfait; le marteau doré n'existe pas. Aucun ne s'harmonise en totalité avec tous les cas possibles de formats de texte. Il faut donc prendre soin de faire un choix qui convienne à l'utilisation escomptée du texte formaté.

Solution C++ 14 – std::quoted()

Depuis C++ 14, on trouve dans <iomanip> la fonction std::quoted() qui permet de consommer ou d'émettre des données balisées (par défaut, ces balises sont des guillemets, mais la fonction est paramétrable). Étant donné la complexité du problème de la consommation de données délimitées, vous apprécierez sûrement l'écriture que permet cette fonction :

#include <iomanip>
// etc.
ostream& serialiser(ostream &os, const string &s) {
   return os << quoted(s);
}
istream& deserialiser(istream &is, string &s) {
   if (!is) return is;
   string temp;
   if(is >> quoted(temp))
      s = temp;
   return is;
}

Version simple de la sérialisation : résumé

En résumé, d'un point de vue simple :

• Sérialiser un objet signifie en pondre une représentation ne reposant que sur des types de données primitifs et facilement désérialisable
• L'objet avant sérialisation et sa contrepartie après sérialisation doivent être équivalents, pas nécessairement identiques (les langages de programmation impliqués peuvent ne pas être les mêmes, et les versions des classes impliquées peuvent impliquer des changements structurels internes), ce qui permet d'assurer le respect de l'encapsulation
• La sérialisation de composés se fait de manière récursive (le composé sérialise ses composants selon un ordre connu et documenté)
• La sérialisation en situation d'héritage se fait en respectant le principe d'encapsulation chez les parents, toujours selon un ordre connu et documenté. On sérialisera habituellement les parents avant de sérialiser l'enfant
• Les cas d'agrégation sont à traiter selon le contexte. Habituellement, cela implique un risque de partage des objets constituant l'agrégat, et on tendra à privilégier un schème d'identification unique de chaque objet pour éviter la duplication des objets partagés, ce qui poserait des ennuis sérieux à la reconstitution : si un seul objet se fait pointer par dix clients distincts et si chacun des dix le sérialise de manière indépendante, la désérialisation risque fort de générer (au moins) dix copies de l'objet partagé à l'origine et de briser la cohérence systémique originale
• La sérialisation doit mener à un format tel que l'objet original puisse être reconstitué sans aucune ambiguïté. Ceci implique parfois d'insérer des délimiteurs sur le flux en sortie et de transformer certaines entités pour que leur forme sérialisée soit reconnaissable en tant que telle; on pense au texte en particulier ici, mais aussi à toute séquence (tableau, vecteur, liste) d'éléments en soi sérialisables sur une base individuelle

Généralisation à des flux sur plusieurs types de caractères

Bien que nos exemples soient délibérément simples et limités à des chaînes de caractères sur un byte et aux flux qui les accompagnent, il est facile de généraliser les opérations à n'importe quel type de caractère.

En effet, le type ostream est un alias pour basic_ostream<char>, tout comme istream est un alias pour basic_istream<char>. Il existe dans le standard des spécialisations nommées pour les wchar_t, soit wistream et wostream, tout comme il existe wcout, wcin, wcerr, wclog, wstring, etc. et il est possible d'ajouter nos propres spécialisations sur d'autres types de caractères, au besoin[6].

On ne voudra toutefois pas couvrir chacun de ces cas particuliers un à un (ce serait fastidieux); il est nettement préférable de rédiger nos fonctions de manière générique, sur la base du type de caractère visé. Ainsi, plutôt que d'écrire un truc comme :

ostream& operator<<(ostream &os, const Vecteur3D &v) {
   return os << v.x << v.y << v.z;
}
istream& operator>>(istream &is, Vecteur3D &v) {
   if (!is) return is;
   float x, y, z;
   if (is >> x >> y >> z)
      v = Vecteur3D{x, y, z};
   return is;
}

On préférera généralement écrire :

template <class C>
   basic_ostream<C>& operator<<(basic_ostream<C> &os, const Vecteur3D &v) {
      return os << v.x << v.y << v.z;
   }
template <class C>
   basic_istream<C>& operator>>(basic_istream<C> &is, Vecteur3D &v) {
      if (!is) return is;
      float x, y, z;
      if (is >> x >> y >> z)
         v = Vecteur3D{x, y, z};
      return is;
   }

Outre l'écriture, plus générale mais un peu plus longue, cette approche n'entraîne aucun coût, que des gains.

Sérialisation plus complexe

La sérialisation est, lorsque prise sous un angle général, un problème ouvert. Ne laissez pas la simplicité des cas proposés dans la section précédente vous tromper. Cela dit, il est possible d'en arriver à une proposition de solution raisonnable dans la plupart des cas particuliers.

Examinons donc quelques aléas de la sérialisation dont le traitement exige une démarche un peu plus empreinte de subtilité.

Désérialiser un type pour lequel il n'existe pas de constructeur par défaut

Il arrive qu'il n'existe pas de constructeur par défaut pour un type donné. Par exemple, on présume de la classe Bonhomme proposée plus haut qu'elle expose un constructeur par défaut (voir le code de lire_bonhomme() ci-dessous) or, en temps normal, il est possible que cette option ne soit pas jugée raisonnable pour certaines applications.

// ...
istream& operator>>(istream &is, Bonhomme &b) {
   if (!is) return is;
   string nom;
   Bonhomme::vie_t vie;
   Vecteur3D pos, dir;
   if (!deserialiser(is, nom)) return is;
   if (is >> vie >> pos >> dir)
      b = Bonhomme{nom, vie, pos, dir};
   return is;
}
Bonhomme lire_bonhomme(istream &is) {
   Bonhomme b; // constructeur par défaut
   if (is)
      is >> b;
   return b;
}
// ...

Heureusement, tout n'est pas perdu. On peut très bien désérialiser un objet soumis à de telles contraintes (devant être correctement initialisé dès sa construction) en utilisant une variante du schéma de conception fabrique.

// inclusions... using...
class PasUnBonhomme {};
class Bonhomme {
   // ... voir plus haut ...
public:
   // ... voir plus haut ...
   static Bonhomme deserialiser(istream&);
};

Cette méthode ne doit pas être une méthode d'instance. En effet, comme pour toutes les fabriques, son rôle et de prendre en charge la construction d'une instance; si elle se présentait comme une méthode d'instance, alors nous aurions (à l'occasion) une version du problème de l'oeuf et de la poule.

// inclusions... using...
Bonhomme Bonhomme::deserialiser(istream &is) {
   if (!is) return is;
   std::string nom;
   Bonhomme::vie_t vie;
   Vecteur3D pos, dir;
   ::deserialiser(is, nom);
   if (!(is >> vie >> pos >> dir))
      throw PasUnBonhomme{};
   return Bonhomme{nom,vie,pos,dir};
}

Certains se diront qu'il reste un problème à régler. En effet, lorsqu'un appelant voudra invoquer la méthode Bonhomme::deserialiser(), il lui faudra bien déposer le Bonhomme retourné quelque part, alors ne vient-on pas de créer un nouveau problème de même nature que celle du problème original?

#include "Bonhomme.h"
#include <fstream>
#include <iostream>
int main() {
   // using...
   ifstream ifs{"Bonhomme.txt"};
   auto b = Bonhomme::deserialiser(ifs);
   cout << b << endl;
}

Cas où la structure doit être découverte dynamiquement

Un autre cas problème est celui où l'ordre et le type des objets sérialisés ne sont pas connus a priori. En effet, tous les cas couverts jusqu'ici étaient des cas où le code client savait quels étaient les types des objets sérialisés et dans quel ordre ces types apparaissaient dans le flux.

Ces cas sont très fréquents : sérialiser un bonhomme implique sérialiser son nom, sa vie, sa position et sa direction; chacune de ces sérialisations est un problème fermé en soi. Le problème de découverte dynamique des types sérialisés apparaît quand les objets à sérialiser sont manipulés de manière polymorphique, donc lorsque le programme opère sur des abstractions plutôt que sur des types concrets ou sur des instances de classes terminales.

L'approche OO préconise l'abstraction dans bien des cas; il nous faut donc réfléchir à un schème convenable pour les cas reposant sur des abstractions comme pour les cas reposant sur des types concrets.

Quelques présupposés s'imposent d'eux-mêmes :

• Le format selon lequel les données sérialisées sont représentées est connu de tous les homologues impliqués dans la sérialisation comme dans la désérialisation
• Le processus qui désérialisera est en mesure de reconnaître et de reconstituer un équivalent de tous les types ayant été sérialisés sur le flux
• Si un langage OO supporte pleinement la réflexion au sens dynamique, alors il est possible de pousser plus loin nos présupposés, mais nous ne le ferons pas ici, les exemples de notre démarche étant en C++, un langage principalement orienté vers le savoir à la compilation

Un autre rappel des constats fondamentaux de la sérialisation doit être fait avant de poursuivre :

• Sérialiser un objet est un procédé subjectif, OO au sens classique de l'objet acteur. Un objet existant saura se projeter lui-même sur un flux
• Désérialiser un objet est un procédé objectif, au sens où l'objet à désérialiser n'est pas actif au préalable. Ce procédé doit donc s'implanter de prime abord par des outils et stratégies qui ne sont pas décrits sous forme de méthodes d'instance du type en cours de désérialisation. On aura recours à des fonctions globales, à des méthodes de classe ou à des intermédiaires

Étant donné qu'un type peut être utilisé pour fins de sérialisation simple ou à travers un mécanisme qui permettra sa désérialisation à l'aide de détection dynamique de types, nous ferons en sorte d'éviter de modifier le schème de sérialisation normal, privilégiant plutôt une stratégie qui enrobera la forme primitive de la sérialisation d'un objet à l'aide d'information susceptible d'assister le mécanisme de désérialisation.

Imposer une structure non locale

Permettre la désérialisation sans connaissance a priori de l'ordre des types sérialisés demande un effort de programmation nettement plus important que ce que nous avons fait dans le cas de la sérialisation simple.

Tout d'abord, il faut que l'entité responsable de désérialiser les objets soit en mesure reconnaître le type de chacun d'eux dans le flux. Les moteurs comme Java et .NET, qui offrent un support intrinsèque à la mécanique de sérialisation, le font implicitement dans un format qui leur est propre lorsque des objets sont écrits sur un flux.

Plusieurs schèmes sont possibles pour identifier les types, revenant la plupart à l'emploi de numéros uniques ou de noms uniques pour chaque type. En situation d'agrégation, identifier les instances de manière unique devient aussi précieux (et la numérotation doit être unique au monde dans certains schèmes globaux comme ceux destinés à des applications dans Internet).

Ce qui complique un peu les choses est que les schèmes de numérotation dynamique, où chaque type se donne une identification unique au démarrage d'un programme, compliquent la sauce lors de la désérialisation.

Pour que le processus responsable de la désérialisation s'y retrouve, il importe que le schème d'identification soit statique, donc connu a priori par les deux homologues de la relation.

Information dynamique de type

Une stratégie serait de tenir à jour une liste d'entiers, soit un pour chaque classe pertinente à sérialiser, mais ce schème rend ardu le contrôle des versions et de l'évolution du logiciel.

Il existe toutefois un moyen, même avec C++, d'identifier de manière unique chaque classe, soit d'utiliser le même schème de nomenclature que celui utilisé par le compilateur dans sa propre génération de code.

En effet, si le code d'un module est compilé de manière à inclure l'information dynamique sur les types (Run-Time Type Information, RTTI), alors il est possible de découvrir à l'exécution un peu d'information sur chaque type, incluant les classes polymorphiques, les classes concrètes et les types primitifs.

Utiliser RTTI implique (forcément) accepter un léger accroissement de la taille du code généré. Abuser des mécanismes d'inférence explicite de types a un impact négatif sur la qualité de l'implémentation et est habituellement signe de fautes de design.

L'information dynamique de type pour un type donné sous C++ est codée dans une instance de la classe std::type_info. Il n'est pas possible d'instancier cette classe directement dans un programme, la grande majorité de ses attributs (et tous ses constructeurs) étant privés; pour connaître l'information de type pour un type T, il faut avoir recours à l'opérateur typeid() prenant en paramètre le nom du type et retournant une référence-vers-const sur l'instance de std::type_info correspondante.

La classe std::type_info expose en particulier une méthode d'instance nommée name(). Cette méthode retourne ce que nous nommerons le nom lisible, correspondant au nom tel qu'on le voit dans le programme.

Un petit programme proposant un exemple d'utilisation de std::type_info et de l'opérateur typeid() suit.

#include <iostream>
#include <string>
#include <typeinfo>
class Bonhomme;
int main() {
   using namespace std;
   cout << typeid(string).name() << endl << endl
        << typeid(Bonhomme).name() << endl endl << endl
        << typeid(int).name() << endl << endl
        << typeid(float).name() << endl << endl;
}

Ce programme affiche à la console (avec Visual Studio 2012) le texte suivant, dans lequel je vous invite à remarquer la différence entre nom lisible et nom décoré pour chaque type.

class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >

class Bonhomme

int

float

Noms statiques de types

Étant donné le caractère non portable des noms retournés par la méthode name() d'une instance de std::type_info, il devient raisonnable de s'interroger sur la possibilité d'avoir un schème de nommage des types qui soit à la fois portable et inclusif pour tous les types, qu'il s'agisse de classes ou de types primitifs.

Il se trouve que la technique des traits permet d'établir un schème statique et portable de nommage pour les types dans un programme donné. Puisque nommer les types pertinents un à la fois peut être fastidieux, voici un exemple utilisant le résultat de la méthode name() de std::type_info(T) en général mais utilisant des noms définis par programmation dans certains cas particuliers.

#include <iostream>
#include <typeinfo>
#include <string>
// using...
class Bonhomme;
template <class T>
   struct traits_type {
      static string nom()
         { return typeid(T).name(); }
   };
//
// Exemple de spécialisation
//
template <>
   struct traits_type<string> {
      static string nom()
         { return "class std::string"; }
   };
int main() {
   // using ...
   cout << traits_type<string>::nom() << endl
        << traits_type<Bonhomme>::nom() << endl
        << traits_type<int>::nom() << endl
        << traits_type<float>::nom()<< endl;
}

Cet exemple montre comment, en général, il serait possible d'utiliser le mécanisme intégré mais non portable, puis de spécialiser le comportement de traits_type pour certains types, mais notez que le cas extrême serait de spécialiser pour tous les types... et ce cas est plausible.

Nous privilégierons le nom lisible au nom décoré dans notre processus de formalisation de la sérialisation des types, sachant que le nom décoré peut différer d'une plateforme à l'autre et que la stratégie pour générer un nom décoré dans un compilateur donné peut ne pas être documentée de manière publique.

Au passage, remarquez que le nom lisible contient souvent des caractères d'espacement, ce qui implique que nous devrons lui appliquer la même stratégie que celle appliquée aux autres chaînes de caractères.

Une stratégie générale et simple de sérialisation en situation de découverte dynamique des types est de préfixer chaque entité par son nom descriptif. Ceci se prête particulièrement bien à de la programmation générique.

#ifndef SERIALISATION_OUTILS_H
#define SERIALISATION_OUTILS_H
#include <iosfwd>
#include <string>
#include <sstream>
//
// Exemple un peu abusif; on pourrait faire plus
// simple avec de la surcharge de fonctions
//
template <class T>
   struct Serialisation {
      static string formater(const T &val) {
         stringstream sstr;
         sstr << '\"' << typeid(T).name() << "\" "
              << val;
         return sstr.str();
      }
   };
template <>
   struct Serialisation<string> {
      static string formater(const string &val) {
         stringstream sstr;
         sstr << '\"' << typeid(string).name() << "\" "
              << '\"' << val << '\"';
         return sstr.str();
      }
   };
#endif

Évidemment, si le besoin s'en fait sentir, il y a lieu d'offrir des spécialisations supplémentaires de cette stratégie pour d'autres types. De même, si la forme sérialisée n'est pas une chaîne de caractères mais bien un format plus compact, la même stratégie peut s'appliquer (peut-être de manière à retourner un vecteur de bytes bruts).

int main() {
   // using...
   const string fich = "Test.dat";
   Bonhomme b{"Fred Emile", 50, Vecteur3D{5, 5, 5}};
   cout << Serialisation<Bonhomme>::formater(b);
   ofstream ofs{fich};
   ofs << Serialisation<Bonhomme>::formater(b);
}

...et la chaîne affichée serait celle ci-dessous :

"class Bonhomme" "Fred Emile" 50 5 5 5 1 0 0

Le préfixe "class Bonhomme" est ce qui nous manquait pour être en mesure de mettre en place une stratégie de désérialisation et de reconstruction à partir d'un flux.

Jusqu'où aller?

Il n'est pas nécessaire de pousser la mécanique de sérialisation assistée à l'extrême et de préfixer toute donnée primitive d'une information descriptive de type, même s'il est techniquement possible de le faire.

L'objectif derrière la stratégie d'insertion de préfixes dans la forme sérialisée est de permettre à la mécanique de désérialisation de se guider sans connaître a priori la liste ordonnée des types sérialisés. Si le processus de désérialisation connaît au préalable la structure exacte de la forme sérialisée, alors il n'a pas besoin de cette information. De même, si le processus de désérialisation rencontre le préfixe de la classe Bonhomme, alors il devra désérialiser un Bonhomme, ce qui lui suffit probablement; si la structure interne d'un Bonhomme est connue du programme, alors pas besoin de préfixer chaque attribut de chaque Bonhomme pour le désérialiser.

Souvenons-nous que la forme selon laquelle sont sérialisées les données doit être connue des deux homologues. Il est raisonnable d'être pragmatique (pour faire une sorte de pléonasme volontaire).

Le problème de la reconstruction : une approche pragmatique

La reconstruction lors d'une désérialisation est plus complexe à mettre en place que la sérialisation, et ce pour plusieurs raisons documentées dans tout bon manuel de POO.

Entre autres choses, il est relativement facile de mettre en place une mécanique de sérialisation homogène et universelle : il suffit de ramener le problème à celui de projection subjective de tout type à une forme commune et d'en retirer les ambiguïtés potentielles.

La destination vers laquelle sont projetées les formes sérialisées est un flux; dans la mesure où la forme sérialisée se projette avec aisance sur un flux, la sérialisation est un dossier à peu près clos. La désérialisation et la reconstruction des objets à partie d'une forme sérialisée n'accepte pas de solution universelle

Pensez-y bien : lors d'une sérialisation, le programme sait ce qu'il sérialise et peut simplement demander à chaque objet de se sérialiser lui-même. La destination et la forme sont toujours homogènes, ce qui fait de la sérialisation une simple application d'une opération sur une séquence.

Le problème d'une désérialisation dynamique des objets, donc sans connaissance a priori de la structure et de l'ordre des objets sérialisés, peut s'exprimer comme ceci :

• Quels objets doit-on reconstruire? Si on ne connaît pas au préalable les types à reconstruire, comment se réserver de l'espace et des variables pour y arriver? Ce problème est avant tout un problème de décision
• Où déposer les objets une fois ceux-ci reconstruits? Si on ne sait même pas quelles variables utiliser lors de la reconstruction, alors où déposera-t-on les objets? Ce problème inclut celui de toutes les actions à réaliser une fois un objet reconstruit (démarrer un thread, assurer les liens vers l'objet reconstruit, reconstituer des liens entre les objets, etc.)

Constat fondamental : toute solution sera nécessairement dépendante du contexte. Un jeu vidéo reconstruisant un monde peuplé d'avatars voudra peut-être déposer les avatars reconstruits dans un vecteur d'avatars mais déposer les bâtiments à la fois dans une liste ordonnée d'objets fixes sur une grille et de structures dessinables.

Autre constat fondamental : les objets ne doivent pas se reconstruire eux-mêmes, bien qu'ils puissent contribuer à leur reconstruction. Tout comme la problématique de la sérialisation formatée est une problématique transversale au modèle OO[8], la problématique de la désérialisation et de la reconstruction est un problème de fabrication d'objets à partir d'une forme protocolaire, qui entraînera éventuellement une construction à partir d'une forme sérialisée.

#ifndef SERIALISATION_OUTILS_H
#define SERIALISATION_OUTILS_H
#include <iosfwd>
#include <string>
#include <vector>
#include <memory>
//
// using, outils de sérialisation et de
// désérialiation, omis pour d'économie
//
class Reconstructeur {
   string nom_lisible_;
public:
   Reconstructeur(const string &nom_lisible)
      : nom_lisible_{nom_lisible}
   {
   }
   virtual ~Reconstructeur() = default;
   string nom_lisible() const
      { return nom_lisible_; }
   virtual void reconstruire(istream &) = 0;
};
#include "Incopiable.h"
class Deserialiseur : Incopiable {
   vector<unique_ptr<Reconstructeur>> reconstr_;
   Deserialiseur() = default;
public:
   bool deserialiser(istream &);
   static Deserialiseur &get() {
      static Deserialiseur singleton;
      return singleton;
   }
   void ajouter(unique_ptr<Reconstructeur> p)
      { if (p) reconstr_.push_back(p); }
};
#endif

Le schéma de conception singleton devrait vous être familier à ce stade-ci. Comme pour tous les singletons, prenez soin d'y ajouter des mécanismes de synchronisation s'il est sujet à être placé en situation de concurrence.

La fabrique peut par contre vous sembler un peu hors normes, mais notez qu'il ne servirait à rien de faire retourner un type autre que void à la méthode de reconstruction du fait que tout type peut y être reconstruit.

#include "SerialisationOutils.h"
#include <iostream>
#include <algorithm>
#include <locale>
#include <string>
#include <vector>
// using...
bool Deserialiseur::deserialiser(istream &is) {
   if (!is) return false;
   string s;
   if (!::deserialiser(is, s)) return false;
   auto it = find_if(
      begin(reconstr_), end(reconstr_),
      [&](unique_ptr<Reconstructeur> &p) {
         return s == p->nom_lisible();
      });
   if (it == end(reconstr_)) return false;
   (*it)->reconstruire(is);
   return true;
}
// fonctions globales serialiser() et
// deserialiser() omises pour fins d'économie

class ReconstruireBonshommes : public Reconstructeur {
   vector<Bonhomme> &bonshommes_;
public:
   ReconstruireBonshommes(vector<Bonhomme> &v)
      : Reconstructeur{ traits_type<Bonhomme>::nom() },
        bonshommes_{v}
   {
   }
   void reconstruire(istream &is) {
      Bonhomme b;
      if (is >> b)
         bonshommes_.push_back(b);
   }
};

Un programme de démonstration simple capable de sérialiser un Bonhomme puis de le désérialiser en découvrant dynamiquement son type et en appliquant la stratégie de fabrication appropriée suit :

// inclusions ...
int main() {
   // using ...
   const string fich = "Test.dat";
   {
      Bonhomme b("Fred Emile", 50, Vecteur3D(5, 5, 5));
      cout << Serialisation<Bonhomme>::formater(b);
      ofstream ofs{fich};
      ofs << Serialisation<Bonhomme>::formater(b);
   }
   vector<Bonhomme> v;
   Deserialiseur::get().ajouter(new ReconstruireBonshommes(v));
   for (ifstream ifs{fich}; Deserialiseur::get().deserialiser(ifs); )
      ; 
   copy(begin(v), end(v), ostream_iterator<Bonhomme>(cout, "\n"));
}

Remarquez que ce code est aussi approprié dans le cas où on ne manipule aucune instance de Bonhomme que dans le cas où il y en a une ou plusieurs.

Application de la sérialisation : infrastructure générique de paramètres

Imaginons que nous ayons besoin d'une hiérarchie d'objets susceptibles d'être sollicités à l'aide de paramètres. Pensons par exemple, un système où plusieurs événements doivent se produire en fonction de conditions précises, parmi lesquels on compte (pour les fins de l'illustration) :

• Des événements liés à un moment particulier, chacun étant construit à l'aide du moment auquel il doit se produire
• Des événements liés au passage d'un acteur dans une zone (représentée par une sphère pour fins de simplicité)
• Des événements liés au changement d'état d'un objet, pour que l'état du jeu soit ajusté en conséquence de ce changement d'état; etc.

La signature du modèle vers lequel nous orienterons ici notre réflexion ira comme suit :

• Un thread générique pourra itérer à travers tous les événements du système pour leur donner une opportunité de réagir à l'état courant du monde, ce qui implique qu'un seul et même thread pourra traiter tous les événements en tant qu'événements. Le concept d'événement sera une abstraction, une racine polymorphique
• Puisque tout événement, pour qu'on puisse le traiter comme un événement, devra respecter une interface stricte (celle de l'abstraction Evenement), il faudra lui fournir à la construction les paramètres dont il aura besoin pour faire son travail. Par exemple, dans le cas d'un événement devant se provoquer à un moment précis, le moment en question devra être connu de l'événement au moment de sa construction
• Pour assurer une encapsulation aussi stricte que possible du concept d'événement et pour éviter de disséminer partout dans le système des détails techniques à son sujet, nous aurons recours à une fabrique d'événements (exprimé simplement : une méthode de classe creer() dans la classe Evenement prenant en paramètre un identificateur pour le type d'événement désiré et une liste générique de paramètres – le sujet de cette section – et retournant un Evenement* ou un pointeur intelligent vers un Evenement)
• Une fois construits, nous présumerons que les événements ont tous accès à l'état du monde. Pour simplifier la signature de la méthode permettant à un événement de se provoquer[10], nous présumerons qu'il existe pour tout événement un moyen d'avoir accès aux parties de l'état du monde qui lui sont pertinents (ce qui serait vrai si le monde était un singleton, par exemple). Dans le cas contraire, l'état du monde serait passé (par référence!) en paramètre à la méthode par laquelle un événement est appelé à se provoquer (ou non)

void reagir(Evenement *p)
   { if (p) p->reagir(); }
unsigned long __stdcall ThEvenements(void *) {
   auto &monde = Monde::get();
   auto &ges = GestionnaireEvenements::get();
   // itérer jusqu'à la fin de la partie
   while (!monde.fin()) {
      ges.reagir();
      // dodo...
   }
   return {};
}

Ce site Web offre une version OO de la démarche proposée ici, avec objets autonomes, outils de synchronisation OO, singletons etc. Le choix de ne pas entrer dans le détail ici est volontaire puisque notre propos porte sur la construction d'un modèle de paramètres génériques.

D'ailleurs, à quoi un paramètre générique ressemblerait-il?

#ifndef PARAMETRE_H
#define PARAMETRE_H
#include <sstream>
class Param {
   stringstream flux_;
public:
   Param() = default;
   template <class T>
      Param(T &&val)
         { *this << val; }
   Param(const Param &p)
      { flux_ << p.flux_.str(); }
   template <class T>
      Param& operator<<(T &&val) {
         flux_ << val << ' ';
         return *this;
      }
   template <class T>
      Param& operator>>(T &val) {
         flux_ >> val;
         return *this;
      }
   Param& operator=(const Param &p) {
      if(this == &p) return *this;
      flux_.clear();
      flux_ << p.flux_.str();
      return *this;
   }
};
// ...

Remarquez aussi que la version de Param proposée ici ne tient pas à jour un nom pour chaque paramètre. Le concept de Param est autosuffisant sans injection d'un nom s'il doit y avoir correspondance entre ordre d'insertion (par le créateur du Param) et ordre d'extraction (par son utilisateur). Pour des structures plus complexes, le type Params (avec un « s ») suit.

La tâche de garder une correspondance avec un nom n'est donc pas essentielle au concept de paramètre. Il est ainsi possible d'avoir les listes de paramètres nommés si le besoin s'en fait sentir, en associant un nom à chaque paramètre de manière non intrusive, tout comme il est possible d'escamoter l'emploi d'un nom pour les applications où cela serait redondant et coûteux.

// ...
#include <string>
#include <map>
#include <algorithm>
// using...
class Params {
   map<string,Param> params_;
public:
   class Redondant {};
   Params() = default;
   Params(const string &nom, const Param &p)
      { ajouter(nom, p); }
   void ajouter(const string &nom, const Param &p) {
      if (params_.find(nom) != end(params))
         throw Redondant{};
      params_[nom] = p;
   }
   Param get(const string &nom) {
      return const_cast<map<string,Param>&>(params_)[nom];
   }
};
#endif

#ifndef OCCURRENCE_H
#define OCCURRENCE_H
class Occurrence {
   bool expire_;
public:
   OccurrenceEvenement() : expire_{} {
   }
   bool est_expire() const
      { return expire_; }
   void expiration()
      { expire_ = true; }
   virtual void reagir() = 0;
   virtual ~Occurrence() = default;
};
// ...

// ...
#include "Incopiable.h"
#include "Parametre.h"
#include <mutex>
#include <string>
#include <map>
#include <vector>
#include <memory>
class FabEvenements {
public:
   using type_t = string;
   struct Fabrique {
      unique_ptr<Occurrence>
         creer(const Params &p = {}) {
         return creer_impl(p);
      }
      virtual ~Fabrique() = default;
   protected:
      virtual unique_ptr<Occurrence>
         creer_impl(const Params &) = 0;
   };
private:
   map<type_t, unique_ptr<Fabrique>> fabriques_;
   FabriqueEvenements();
   std::mutex mutex_;
public:
   class TypeInconnu {};
   vector<type_t> types() const;
   static FabEvenements &get() {
      static FabEvenements singleton;
      return singleton;
   }
   unique_ptr<Occurrence> creer(const type_t&, const Params& = {});
};
#endif

#include "Occurrence.h"
#include <mutex>
#include <ctime>
#include <iostream>
// using...
class EvenementMoment : public Occurrence {
   time_t moment_;
public:
   EvenementMoment(time_t moment) : moment_{moment} {
   }
   time_t moment() const
      { return moment_; }
   void reagir() {
      if(time(nullptr) >= moment()) {
         cout << "\a\a\a";
         expiration();
      }
   }
};
// ...

Pour chaque catégorie d'événement, il faudra une paire faite d'une fabrique et d'un nom.

// ...
class FabTemps : public FabEvenements::Fabrique {
   unique_ptr<Occurrence> creer_impl(const Params &p) {
      Param paramMoment = p.get("Quand");
      time_t quand;
      paramMoment >> quand;
      return make_unique<EvenementMoment>(quand);
   }
};
// ...

La généricité, en ce sens, a ses limites : comme dans toute tâche de programmation, il est nécessaire (du moins pour être efficace) que le code client sache parler au code serveur et que le client connaisse les types et les noms des paramètres lors d'une invocation de méthode ou lors de la création d'un objet.

// ...
FabEvenements::FabEvenements() {
   fabriques_["EvenementTemps"] = make_unique<FabTemps>();
}
// ...

Si le nom des types d'événements doit servir de clé, alors il peut être utile d'offrir un service listant ces noms, quand bien même ce ne serait que pour concevoir des outils de développement. Plusieurs stratégies sont possibles pour mettre en place un tel service.

// ...
#include <algorithm>
#include <vector>
auto FabEvenements::types() const -> vector<type_t> {
   lock_guard<mutex> av {mutex_};
   vector<type_t> v;
   FabEvenements &temp(
      const_cast<FabEvenements&>(*this)
   );
   for(const auto &fab : fabriques_)
      v.push_back(fab->first);
   return v;
}
// ...

Enfin, il nous reste à explorer la méthode de fabrication d'événements sur demande.

// ...
unique_ptr<Occurrence> FabriqueEvenements::creer(const type_t type, const Params &p) {
   lock_guard<mutex> av(mutex_);
   if (fabriques_.find(type) == end(fabriques_))
      throw TypeInconnu{};
   return fabriques_[type]->creer(p);
}

Un exemple de programme de test simpliste suit.

int main() {
   auto v = FabEvenements::get().types();
   // obtenir les noms des types d'événements inscrits
   for(const auto &type : v)
      cout << "Type: " << type << endl;
   // creer un événement
   auto p = FabEvenements::get().creer(
      "EvenementTemps", Params("Quand", Param(time(nullptr)+2))
   );
   // le provoquer jusqu'à épuisement
   while(!p->est_expire()) p->reagir();
}

Lectures complémentaires

Il existe des tas d'approches à la sérialisation. Vous pouvez entre autres jeter un coup d'oeil à http://www.codeproject.com/Articles/225988/A-practical-guide-to-Cplusplus-serialization tiré du Code Project et qui utilise la bilbiothèque Boost.

Ce texte de 2014 par Mark Nelson propose une approche générique aux entrées/ sorties de bits, ce qui peut être utile entre autres pour résoudre des problèmes de compression de données : http://www.drdobbs.com/cpp/bit-oriented-io-with-templates/240168766

Texte de Martin C. Martic en 2015 sur les difficultés inhérentes à la sérialisation binaire avec C++ : http://martincmartin.com/2015/02/02/writing-to-a-binary-stream-in-cc-harder-than-it-should-be/

Survol très bref de quelques enjeux la sérialisation avec C++, par Tony Da Silva en 2015 : http://bulldozer00.com/2015/07/27/is-it-safe-2/

Sérialisation en C++, technique s'appuyant sur une forme de réfléxivité dynamique, texte du Code Project par Phillip Voyle en 2015 : http://www.codeproject.com/Tips/1000274/Can-You-Serialize-Objects-to-and-from-Cplusplus

En 2016, Sergey Ignatchenko et Dmytro Ivanchykhin proposent une technique de sérialisation qu'ils qualifient d'ultra-rapide : https://accu.org/index.php/journals/2317#[NoBugs15

[1] Donc nous ne voulons pas savoir quels attributs, dans quel ordre, avec ou sans espace vide entre les attributs pour accélérer l'accès aux données alignées sur la taille d'un mot mémoire, etc.

[2] En effet, un enfant ne veut pas connaître (ou dépendre de) l'organisation interne des états de ses parents, non plus que l'ordre selon lequel chacun apparaît en lui. Ce serait à la fois un bris d'encapsulation et un solide cauchemar d'entretien de code.

[3] L'encapsulation, par nature, fait en sorte que d'exiger que l'objet reconstitué soit identique à l'objet originalement sérialisé soit superflu.

[4] Nous aurions pu utiliser n'importe quel caractère d'espacement ici, incluant des tabulations et des sauts de ligne. Cela dit, l'usage est de laisser le sous-programme réalisant la sérialisation décider de la forme générale des entités une fois sérialisées (qui va sur quelle ligne? Y aura-t-il de l'indentation?). Chaque entité se sérialisera habituellement elle-même de la manière la plus simple possible.

return os << serialiser(os, b.nom())
          << b.vie();

[5] Évitez donc quelque chose comme le code proposé à droite car même si cela compilerait sans peine, l'ordre d'invocation des opérateurs pourrait vous causer des surprises.

[6] Par exemple pour couvrir le cas des unsigned char, utile pour fins d'interopérabilité avec COM ou CORBA, ou pour utiliser nos propres classes se comportant comme des caractères.

[7] Une fonction globale ferait aussi l'affaire.

[8] Un objet doit savoir se sérialiser, mais l'insertion d'information de contrôle autour de la forme sérialisée est un problème de protocole, qui peut changer d'une application à l'autre sans que les objets n'aient à le savoir. On parle donc d'une application de programmation générique ou de programmation orientée aspect (POA).

[9] Notez le verbe : on pourrait, pas on devrait. Il existe plusieurs manières de gérer la dynamique d'un système, et il n'est pas clair qu'une gestion $100\%$ réactive soit souhaitable. Les événements nous serviront ici d'illustration pour une stratégie permettant de construire des objets à partir de paramètres génériques; d'autres illustrations auraient pu être envisagées.

[10] Nous prenons une approche OO ici, ce qui implique que plutôt que de provoquer les événements, ceux-ci se provoquent en fonction de critères qui leur sont propres.

[11] Au plus simple, un objet autonome encapsulé dans un singleton, qui garde à jour dans un attribut une valeur (probablement entière) représentant le moment présent, et permettant une consultation synchronisée de cette valeur.