Discussion :

[bolhrak]

Bonjour,

Petite question sur la mise en oeuvre de la programmation par contrat en C++. Dans la mesure où l'on n'a pas de syntaxe spécifique pour spécifier les contrats (comme des clauses requires en ensures par exemple), comment peut-on les spécifier autrement que par des commentaires ?

Les asserts en début de méthodes pour vérifier les préconditions sont pour moi une forme déguisée de test sur les préconditions, chose que l'on n'est pas sensé faire.

Les ruptures de contrat sont sensées lever des exceptions, comment le faire si on ne vérifie pas les conditions ?

Merci d'avance.

[Aurelien.Regat-Barrel]

J'ai entendu parler de techniques de ce genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class Test
{
public:
    void DoSomething();
private:
    virtual void DoSomethingImpl() = 0;
};
 
void Test::DoSomething()
{
    // verification des preconditions
    this->DoSomethingImpl();
    // verification des post conditions
}

Les implémentations héritent de Test, et le client utilise uniquement les fonctions publiques non virtuelles de Test.

On peut imaginer des solution a base de template wrapper...

[bolhrak]

Oui mais il y a dans ce code les vérifications des conditions, chose qu'on est sensé éviter de faire.

Le fait d'utiliser de wrapper les méthodes virtuelles par des non virtuelles permet juste d'isoler proprement l'interface de l'implémentation (on pourrait carrément aller plus loin en appliquand l'idiome Pimpl).

Rajouter les vérifications des conditions dans les méthodes virtuelles contredit la règle selon laquelle une méthode n'est pas sensé tester sa précondition. A moins que cette règle soit basée sur la possibilité du langage de spécifier et vérifier les pré et post conditions de manière transparente. Dans ce cas on a pas d'autres choix en C++ que de tester ces conditions, mais je ne sais pas si on peut toujours parler de programmation par contrat du coup

[Sylvain Togni]

Oui mais il y a dans ce code les vérifications des conditions, chose qu'on est sensé éviter de faire.

Je ne comprend pas ce que tu veux dire, le C++ ne supportant pas nativement la programmation par contrat, il faut forcement faire les vérifications "à la main" . Que ce soit les pré-conditions, les post-conditions ou les invariants, on les indiques par des commentaires dans le .h et on les vérifie avec des assert() ou équivalent dans l'implémentation.

À noter que les exceptions ne sont pas une bonne façon de gérer les erreurs de contrat.

[bolhrak]

Je ne comprend pas ce que tu veux dire, le C++ ne supportant pas nativement la programmation par contrat, il faut forcement faire les vérifications "à la main" . Que ce soit les pré-conditions, les post-conditions ou les invariants, on les indiques par des commentaires dans le .h et on les vérifie avec des assert() ou équivalent dans l'implémentation.

Disons que les vérifications à la main me paraissent plutôt orientées programmation défensive, donc à l'opposé de ce que propose la programmation par contrat.

À noter que les exceptions ne sont pas une bonne façon de gérer les erreurs de contrat.

A cause de la perte de contexte ? Dans le cas d'une version DEBUG, l'assert passe, dans le cas d'une release comment signaler à l'appelant que le contrat est rompu autrement que par une exception ? Un arrêt complet de l'exécution n'est aps forcément acceptable.

[Sylvain Togni]

Disons que les vérifications à la main me paraissent plutôt orientées programmation défensive, donc à l'opposé de ce que propose la programmation par contrat.

La programmation par contrat est un type de programmation défensive. Elles ne sont pas opposées.

Dans le cas d'une version DEBUG, l'assert passe

Une version DEBUG, comme le nom l'indique, c'est pour debugger. La programmation par contrat, c'est pour trouver plus facilement les bugs. Il me semble donc normal que les deux soient liés.

dans le cas d'une release comment signaler à l'appelant que le contrat est rompu autrement que par une exception ?

L'appelant n'a pas à savoir si le contrat est rompu, il doit respecter le contrat. S'il ne le respecte pas, c'est un bug, et un arrêt complet est une solution.