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.