Programmation Par Contrat

Il est tout d'abord possible d'ignorer totalement les ruptures de contrats et de ne jamais rien vérifier.

Quand une erreur de programmation survient, et que l'on est chanceux, on détecte le problème au plus proche de l'erreur. Malheureusement, en C et en C++, les problèmes tendent à survenir bien plus tard. Qui n'a jamais expérimenté des plantages qui apparaissent et disparaissent au gré d'ajouts de printf() ?

Cette mauvaise pratique consistant à ignorer les contrats (ou à ne pas s'en préoccuper) est assez répandue. Je ne cache pas que l'un des objectifs de cette série de billets est de combattre cette habitude.

À l'opposé, on peut prendre la voie de la Programmation Défensive et vérifier chaque rupture potentielle de contrat pour lancer une exception. Au-delà des problèmes de conceptions et de déresponsabilisation évoqués dans le billet précédent, il y a un souci technique.

En effet, en temps normal avec une exception en C++, on ne peut rien avoir de mieux que des informations sur le lieu de la détection (i.e. :__FILE__ et __LINE__). Et encore faut-il disposer de classes exception conçues pour stocker une telle information ; ce n'est par exemple pas le cas des std::logic_error qui sont lancées depuis des fonctions comme std::vector<>::at().

Par « rien de mieux que le lieu de la détection », il faut comprendre que l'on ne disposera d'aucune autre information de contexte. En effet, une exception remonte jusqu'à un catch compatible ; or à l'endroit du catch, on ne peut plus avoir accès à l'état (de toutes les variables, dans tous les threads…) au moment de la détection du problème.

En vérité, il y existe des moyens peu ergonomiques pour y avoir accès.

• Un premier consiste à mettre des points d'arrêt sur les lancers ou les constructions d'exceptions, et à exécuter le programme depuis un débugueur -- cf. catch throw dans gdb.
• Un second consiste à supprimer du code source tous les catchs qui sont compatibles avec l'erreur de logique.
  Pour vous simplifier la vie, et être propres, faites dériver vos erreurs de logique de std::logic_error (et de ses enfants) et vos erreurs de runtime de std::runtime_error (& fils) ; enfin dans votre code vous pourrez ne pas attraper les std::logic_error lorsque vous ne compilez pas en définissant NDEBUG histoire d'avoir un coredump en Debug sur les erreurs de logique, et une exception en Release. J'y reviendrai dans le prochain billet.
  Le hic est que de nombreux frameworks font dériver leurs erreurs de std::exception et non de std::runtime_error, et de fait, on se retrouve vite à faire des catch(std::exception const&) aux points d'interface (dialogue via API C, threads en C++03, main()…) quel que soit le mode de compilation.
  Corollaire : ne faites pas comme ces frameworks et choisissez judicieusement votre exception standard racine.

Aucune de ces deux options n'est véritablement envisageable pour des tests automatisés ; et la seconde l'est encore moins pour du code qui va aller en production. Ces options sont en revanche envisageables pour investiguer.

À noter aussi qu'avec cette approche, on paie tout le temps un coût de vérification des contrats, que cela soit en phase de tests comme en phase de production. Et ce, même pour des morceaux de code où il est certain qu'il n'y a pas d'erreur de programmation.
Par exemple, sqrt(1-sin(x)) ne devrait poser aucun souci. Une fonction sinus renvoie en théorie un nombre entre -1 et 1, ce qui constitue une postcondition tout indiquée. De fait par construction, 1-sin(x) est positif, et donc compatible avec le contrat de sqrt.

En vérité, il existe une troisième façon de s'y prendre. Sous des systèmes POSIX, on peut déclencher des coredumps par programmation et ce sans interrompre le cours de l'exécution. Cela peut être fait depuis les constructeurs de nos exceptions de logique (Voir ceci, ou cela).

Le C, et par extension le C++, nous offrent un outil tout indiqué pour traquer les erreurs de programmation : les assertions.

En effet, compilé sans la directive de précompilation NDEBUG, une assertion va arrêter un programme et créer un fichier core. Il est ensuite possible d'ouvrir le fichier core depuis le débugueur pour pouvoir explorer l'état du programme au moment de la détection de l'erreur.

II-C-1. Exemple d'exploitation des assertions▲

// test-assert.cpp
#include <iostream>
#include <cmath>
#include <cassert>
#include <limits>

namespace my {
    /** Computes square root.
     * @pre \c n must be positive, checked with an assertion
     * @post <tt>result * result == n</tt>, checked with an assertion
     */
    double sqrt(double n) {
        assert(n >=0);
        const double result = std::sqrt(n);
        assert(std::abs(result*result - n) < std::numeric_limits<double>::epsilon() * 100);
        return result;
    }

    /** Computes sinus.
     * @post \c n belongs to [-1, 1], checked with an assertion
     */
    double sin(double n) {
        const double r = std::sin(n);
        assert(r <= 1 && r >= -1);
        return r;
    }
} // my namespace


int main ()
{
    std::cout << my::sqrt(my::sin(0)-1) << std::endl;
}
// Vim: let $CXXFLAGS='-g'

$ ./test-assert
assertion "n >=0" failed: file "test-assert.cpp", line 14, function: double my::sqrt(double)
Aborted (core dumped)

$ gdb test-assert
GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
..
Reading symbols from /cygdrive/c/Dev/blog/source/_posts/test-assert...done.
(gdb) run
Starting program: /cygdrive/c/Dev/blog/source/_posts/test-assert
[New Thread 5264.0xe2c]
[New Thread 5264.0x6fc]
assertion "n >=0" failed: file "test-assert.cpp", line 14, function: double my::sqrt(double)

Program received signal SIGABRT, Aborted.
0x0022da18 in ?? ()

(gdb) bt
#0  0x0022da18 in ?? ()
#1  0x7c802542 in WaitForSingleObject () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#2  0x610da840 in sig_send(_pinfo*, siginfo_t&, _cygtls*) () from /usr/bin/cygwin1.dll
#3  0x610d7c7c in _pinfo::kill(siginfo_t&) () from /usr/bin/cygwin1.dll
#4  0x610d8146 in kill0(int, siginfo_t&) () from /usr/bin/cygwin1.dll
#5  0x610d8312 in raise () from /usr/bin/cygwin1.dll
#6  0x610d85b3 in abort () from /usr/bin/cygwin1.dll
#7  0x61001aed in __assert_func () from /usr/bin/cygwin1.dll
#8  0x004011d3 in my::sqrt (n=-1) at test-assert.cpp:14
#9  0x0040125a in main () at test-assert.cpp:33

(gdb) up 8
#8  0x004011d3 in my::sqrt (n=-1) at test-assert.cpp:14
7               assert(n >=0);
(gdb) p n
$1 = -1

II-C-2. Un outil pour les phases de développement et de tests…▲

II-C-3. … voire de production▲

#if defined(NDEBUG)
#   define my_assert(condition_, message_) \
       if (!(condition_)) throw std::logic_error(message_)
#else
#   define my_assert(condition_, message_) \
       assert(condition_ && message_)
#endif

II-C-4. Techniques connexes▲

assert(n>=0 && "sqrt can't process negative numbers");

switch (myEnum) {
    case Enum::first: .... break;
    case Enum::second: .... break;
    default:
        assert(!"Unexpected case");
}

II-C-5. Exploitation des assertions par les outils d'analyse statique de code▲

Quand plus tôt j'indiquais que sinus a pour postcondition toute indiquée un résultat inférieur à 1, peut-être avez-vous tiqué. Et vous auriez eu raison. La postcondition de la fonction sin() est de calculer… un sinus.
Là, plusieurs problèmes se posent : comment valider que le calcul est correct ? Avec une seconde implémentation de la fonction ? À l'aide de cos() ? Et quel serait le prix (même en mode Debug) d'une telle vérification ?

Lors de ses présentations sur le sujet, John Lakos rappelle une postcondition souvent négligée d'une fonction de tri : non seulement, les éléments produits doivent être triés, mais en plus il doit s'agir des mêmes éléments (ni plus, ni moins) que ceux qui ont été fournis à la fonction de tri. [N.B. Cet exemple semble venir de Kevlin Henney.]

Finalement, un consensus semble se dégager vers l'utilisation de tests unitaires pour valider les postconditions de fonctions. Après, je vous laisse juger s'il est pertinent de vérifier par assertion des postconditions simples et peu coûteuses comme le fait que le résultat de sin() doit appartenir à [-1, +1]. D'autant que pour l'instant, aucun (?) outil n'exploite des assertions pour faire de la preuve formelle et ainsi détecter que sqrt(sin(x)-1) est problématique sur certaines plages de x.

Depuis, diverses personnes se sont investies sur le sujet et on est arrivés à la proposition d'évolution p0380r1, et à la spécification formelle p0542r0.

III-A-1. Les contrats▲

III-A-2. Modes et options▲

III-A-3. Limitations▲

void incr(int & r)
    [[expects: 0 < r]]
{
    int old = r;
    ++r;
    [[assert: r = old + 1]]; // faking a post-condition
}

III-A-4. Et maintenant ?▲

Dans la signature d'une fonction, les références posent une précondition : la valeur passée en paramètre par référence doit être non nulle -- à charge au code client de vérifier cela.

Dans le corps de la fonction, elles deviennent pratiquement un invariant : à partir de là, il est certain que la chose manipulée indirectement est censée exister. Il n'y a plus besoin de tester un pointeur, que cela soit avec une assertion (PpC), ou avec un test dynamique (Programmation Défensive).
Certes, cela ne protège pas des cas où la donnée est partagée depuis un autre thread où elle pourrait être détruite.

John Carmack recommande leur utilisation (en place de pointeurs) dans un billet sur l'analyse statique de code initialement publié sur feu #AltDevBlog.

V-A-1. Ou a défaut gsl::non_null▲

Dans le même ordre d'idée que not_null, le problème sqrt pourrait se résoudre avec un type positive_number. Si l'utilisateur néglige de s'assurer de passer un nombre qui offre cette garantie de positivité, le compilateur sera là pour le rappeler à l'ordre, même en C++11 et ses auto.

// Le prérequis
[[expects: x >= 0]] // redondant avec `positive_number`
[[ensures ret_val: abs(ret_val*ret_val - x) <= epsilon]]
positive_number sqrt(positive_number x);

//--------------------------------------------------
// La version où le Responsable UI doit renvoyer un truc positif.
// et qui compilera
positive_number interrogeES();

double metier() {          // écrit par l'Intégrateur
   auto i = interrogeES(); // écrit par le Responsable UI
   return sqrt(i);         // écrit par le Mathématicien
}
// Note: on pourrait effectivement retourner un positive_number, mais faisons
// comme si l'intégrateur n'avait pas vu cette garantie qu'il pourrait offrir,
// vu que ce n'est pas le sujet ici.

//--------------------------------------------------
// La version où le Responsable UI renvoie ce qu'il veut
// et qui ne compilera pas
// metier() reste identique.
double interrogeES();

//--------------------------------------------------
// La version où l'on intègre comme des sagouins
// et qui compile
double interrogeES();
double metier() {
   auto i = interrogeES();
   return sqrt(positive_number(i));
}
// Ça, c'est mal ! On a été prévenu du problème et on le cache sous le tapis.

//--------------------------------------------------
// La version où l'on intègre correctement
// et qui compile
double interrogeES();
double metier() {
   auto i = interrogeES();
   if (i < 0) {
       throw std::range_error("Cannot work on a negative number. Please start again`.")`
   }
   return sqrt(positive_number(i));
}

Le hic avec cette technique prometteuse ?

Il faudrait un positive_number, un not_null_number pour les divisions, un strictly_positive_number et ainsi de suite, et prévoir que la différence entre deux nombres positifs est juste un… nombre. Même si le compilateur optimisera au point de neutraliser le poids de ces surcouches, même avec auto, cela représente beaucoup de travail : des types à définir, les fonctions du standard à encapsuler (imaginez le code d'un pow() sachant reconnaître des puissances entières paires pour retourner dans ces cas précis des positive_number), et un utilisateur possiblement perdu au milieu de tout ça. Heureusement, on n'a pas encore introduit les positive_length. Et puisqu'on parle des unités SI, parlons de boost.unit.

boost.unit est le genre de bibliothèque qui aurait pu sauver une fusée. L'idée est de ne plus manipuler de simples valeurs numériques, mais des quantités physiques. Non seulement on ne peut pas additionner des masses à des longueurs, mais en plus l'addition de masses va prendre en compte les ordres de grandeur.
Bref, on type fortement toutes les quantités numériques selon les unités du Système International.

Un objet devrait toujours avoir pour invariant : est dans un état pertinent et utilisable. Concrètement, cela implique deux choses pour le développeur.

1. Un tel invariant se positionne à la sortie du constructeur de l'objet.
2. On doit retarder la définition/déclaration d'une variable jusqu'à ce que l'on soit capable de lui donner valeur pertinente, et préférentiellement définitive.

Un point de la FAQ C++ de développez traite de cela plus en détail.

Dans la continuité du point précédent, il faut éviter toute initialisation qui se produit après la construction d'un objet. En effet, si l'objet nécessite deux appels de fonction pour être correctement initialisé, il y a de grands risques que le second appel soit purement et simplement oublié. Il faut de fait tester dynamiquement dans chaque fonction de l'objet s'il a bien été initialisé avant de tenter de s'en servir.

Si le positionnement de l'invariant d'utilisabilité se fait en sortie du constructeur, nous aurions à la place la garantie que soit l'objet existe et il est utilisable, soit l'objet n'existe pas et aucune question ne se pose, nulle part.

N.B. Il existe des infractions à cette règle. Une des plus visibles vient du C++ Style Guide de Google. Dans la mesure où les exceptions sont interdites dans leur base de code (car la quantité de vieux code sans exceptions est trop importante), il ne reste plus aucun moyen de faire échouer des constructeurs. On perd l'invariant statique, il devient alors nécessaire de procéder à des initialisations en deux phases.
Si vous n'avez pas de telle contrainte de « pas d'exceptions » sur vos projets, bannissez les fonctions init() de votre vocabulaire.

Ceci dit, le recours à des factories permet de retrouver un semblant d'invariant statique.

Avec le C++11 nous avons l'embarras du choix pour choisir comment manipuler des entités ou des données dynamiques. Entre, std::unique_ptr<>, std::shared_ptr, boost::ptr_vector, les références, les pointeurs bruts (/nus), std::optional<> (C++17), etc., on peut avoir l'impression que c'est la jungle.

Quel rapport avec les invariants statiques ? Et bien, comme pour les références std::unique_ptr<>, apporte une garantie supplémentaire par rapport à un simple pointeur brut. Ce type assure que la fonction qui réceptionne le pointeur en devient responsable alors que l'émetteur s'est débarrassé de la patate chaude. Et le compilateur est là pour entériner la transaction et faire en sorte que les deux intervenants respectent bien ce contrat de passation de responsabilité.

Je pense que j'y reviendrai dans un prochain billet. En attendant, je ne peux que vous conseiller la lecture de cette présentation assez exhaustive d'Ahmed Charles.