"Borne supérieure" pour un template

Bonjour à tous,

Je souhaiterais utiliser un template dans une classe, mais en imposant une "borne supérieure" au type défini dans le template.
Pour ceux qui connaissent le Java, on peut faire quelque chose du genre :

Code:

---

public class A < B extends C > { ... };

---

Cela autorise uniquement l'instanciation d'objets de type :

Code:

---

A<D> objet = new A<D>();

---

avec D un type qui hérite nécessairement de C.

Je voudrais obtenir le même comportement de borne supérieure en C++.
Quelqu'un aurait-il une idée ? Une piste semble être l'utilisation de std::enable_if (valable avec C++11) ...

Je vous remercie d'avance,

C’est une mauvaise idée.

La raison pour laquelle les langages comme java ou c# permettent cela est d’avoir un certain nombre de garanties sur le type que tu vas utiliser, notamment que tu peux appeler certaines fonctions et que ça va marcher.

Mais forcer une classe de base (ou une interface), ce qui est rendu nécessaire par l’implémentation des génériques de java/c#, est un frein à la réutilisabilité de ton code. Le client de ta classe générique doit pouvoir instancier ta classe générique comme il le veut, avec ce qu’il veut, du moment qu’il respecte l’interface requise.

Pour l’instant, il n’y a rien en C++ qui permette de formaliser cette « interface requise ». La notion s’appelle « concept », mais elle est imparfaite, et pas encore intégrée à la norme.

Sans doute faisable à coup de std::enable_if et std::is_convertible.

Hello,

Le gros avantage des templates est justement de ne pas avoir à donner d'interface comme en Java / C#.
Et c'est en général une mauvaise idée de vouloir copier/coller des principes Java en C++ : ça marche différemment.

Si tu connais l'interface de base, tu n'as normalement plus besoin de templates.
Mais si tu veux quand même vérifier le type :

Code:

---

1 2 3 4 5 6 7 8 9 10

struct Base {}; struct Derived : Base {};   template <class T> struct Foo { static_assert(std::is_base_of<Base, T>::value, "wrong type"); };   Foo<int> fi; // lance une erreur de compilation Foo<Derived> fd; // ok

---

Je comprend ce que tu veux dire, mais je suis pas forcément d'accord.

Si je fournis à un client une classe utilisant un template et que dans le code de la classe, je suppose que le type du template réalise une certaine interface et que j'appelle l'une des fonctions requise par cette interface, le client devrait pouvoir le savoir rien qu'avec la définition de la classe.
Je devrais pas avoir besoin de lui dire dans la documentation ; la définition de la classe doit se suffire à elle même.

Au même titre que l'utilisation des exceptions permet de savoir, juste avec la définition d'une méthode, les problèmes qui peuvent être rencontrés, sans être obligé (comme en C notamment) de dire dans la documentation que cette fonction renvoie NULL si il y a un problème, ou 0, ou un nombre négatif, etc ...

Enfin après c'est une question de point de vue, et j'imagine que les deux sont valables.

En tout cas merci pour ta réponse !

Merci Iradrille pour ta réponse.

Citation:

---

Envoyé par Rafiki3931

Je devrais pas avoir besoin de lui dire dans la documentation ; la définition de la classe doit se suffire à elle même.

---

Tu as parfaitement raison sur ce point :ccool:, actuellement C++ a un manque de ce côté-là. Mais contraindre en utilisant une classe de base est une mauvaise solution au problème. La bonne solution (les concepts) devrait arriver dans la prochaine norme.

D'accord, merci pour ton éclairement.
En attendant, ça ne va pas m'empêcher de coder ^^

Merci à tous pour votre participation.

La relation de sous-typage des templates en C++ est fondamentalement structurelle (et meme la variante la plus laxiste habituellement appelee duck-typing). Si tu veux factoriser la definition des contraintes a respecter par un parametre template, la technique idiomatique est de definir un "concept" qui decrit cette contrainte et d'y faire reference, pas d'exiger la derivation a partir d'une classe (ce qui est une forme forte de typage nominal).

A noter que la tension entre typage structurel et nominal est en partie la raison pour laquelle il n'y a pas encore de mecanisme de concept dans le langage.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Si tu veux factoriser la définition des contraintes a respecter par un paramètre template, la technique idiomatique est de définir un "concept" qui décrit cette contrainte et d'y faire référence, pas d'exiger la dérivation a partir d'une classe (ce qui est une forme forte de typage nominal).

---

À partir du moment où est introduite la contrainte de dérivation, ça a trait au typage structurel, pas seulement au typage nominal.
Les concepts étant pour l'instant absents en C++, autant utiliser les fonctionnalités du C++11, telles que std::is_convertible ou std::is_base_of. Sinon, je ne vois vraiment pas à quoi ces dernière pourraient servir.

Citation:

---

Envoyé par oodini

À partir du moment où est introduite la contrainte de dérivation, ça a trait au typage structurel, pas seulement au typage nominal.

---

Typage structurel: un type est un sous-type s'il a la structure desiree. (Le duck typing est une forme faible parce que la structure desiree n'est verifiee que sur ce qui est effectivement utilise, par avec une liste explicite la decrivant).

Typage nominal: un type est un sous-type uniquement s'il est declare comme tel (en plus naturellement d'avoir la structure desiree). Contraindre a avoir une relation de sous-classe est bien du typage nominal, et c'est une version forte parce qu'elle n'est pas definissable a posteriori sans modifier la classe.

OK, au temps pour moi.

Salut,

Citation:

---

Envoyé par Rafiki3931

Si je fournis à un client une classe utilisant un template et que dans le code de la classe, je suppose que le type du template réalise une certaine interface et que j'appelle l'une des fonctions requise par cette interface, le client devrait pouvoir le savoir rien qu'avec la définition de la classe.
Je devrais pas avoir besoin de lui dire dans la documentation ; la définition de la classe doit se suffire à elle même.

---

Citation:

---

Envoyé par white_tentacle

Tu as parfaitement raison sur ce point :ccool:, actuellement C++ a un manque de ce côté-là. Mais contraindre en utilisant une classe de base est une mauvaise solution au problème. La bonne solution (les concepts) devrait arriver dans la prochaine norme.

---

Je ne suis pas d'accord avec vous : la documentation doit être complète et, s'il y a des préconditions à respecter pour pouvoir utiliser une classe, la documentation devrait les indiquer explicitement.

Le code doit se suffire à lui-même, là dessus, nous sommes tout à fait d'accord. Mais cela ne signifie pas que tu ne dois pas créer une documentation correcte, cohérente et complète! Cela signifie "simplement" que les commentaires au niveau du code, destinés d'une manière ou d'une autre à permettre la compréhension du code, devraient être limités aux stricte minimum. Les commentaires qui paraphrasent le code en particulier devraient être proscrits ;).

Par contre, créer un cartouche qui reprend (entre autres) les préconditions et qui explique clairement le but d'une classe ou d'une fonction, qui indique (pour les fonctions) l'utilisation des paramètres s'il y en a, et la valeur de retour à laquelle on peut s'attendre (s'il y en a) est, à mon sens, indispensable.

Car, une fois que l'on a développé une fonction ou une classe, elle sera beaucoup plus utilisée que modifiée. Il faut donc que celui qui utilisera la classe ou la fonction puisse se faire une idée très précise (ou du moins, aussi précise que possible :D) de ce à quoi il peut s'attendre et des points auxquels il doit être attentif durant l'utilisation ainsi que des raisons qui font que c'est la classe ou la fonction en question qu'il devra utiliser de préférence à toute autre ;)

Citation:

---

Envoyé par koala01

Par contre, créer un cartouche qui reprend (entre autres) les préconditions et qui explique clairement le but d'une classe ou d'une fonction, qui indique (pour les fonctions) l'utilisation des paramètres s'il y en a, et la valeur de retour à laquelle on peut s'attendre (s'il y en a) est, à mon sens, indispensable.

---

Je ne suis pas totalement d'accord avec toi sur ce point.

Je m'explique : oui il est indispensable que les préconditions, postconditions et invariant apparaissent dans la documentation générée et soit présents dans le code source à destination d'un humain, d'une manière ou d'une autre.
Mais le fait de devoir le mettre dans le cartouche de commentaire (en plus des éventuels contrôles fait dans le code) n'est pas, à mon avis, la bonne solution seulement une bonne pratique faute de mieux.

Dans ma vision des choses, ce qu'il faudrait c'est de pouvoir les exprimer dans le code de manière explicite et expressive (et donc lisible par un humain), qu'ils soient vérifiés - en debug - lors de l'exécution (et lors de la compilation pour ce qui est vérifiable à ce moment là) et qu'ils soient pris en compte par les outils de génération de documentation type doxygen. A partir de ce moment il n'est plus nécessaire de les rajouter dans le cartouche de commentaires (tout comme ça fait bien longtemps que je ne met plus le nom des fonctions et des classes dans ce fameux commentaire).

Citation:

---

Envoyé par gl

Je ne suis pas totalement d'accord avec toi sur ce point.

Je m'explique : oui il est indispensable que les préconditions, postconditions et invariant apparaissent dans la documentation générée et soit présents dans le code source à destination d'un humain, d'une manière ou d'une autre.
Mais le fait de devoir le mettre dans le cartouche de commentaire (en plus des éventuels contrôles fait dans le code) n'est pas, à mon avis, la bonne solution seulement une bonne pratique faute de mieux.

Dans ma vision des choses, ce qu'il faudrait c'est de pouvoir les exprimer dans le code de manière explicite et expressive (et donc lisible par un humain), qu'ils soient vérifiés - en debug - lors de l'exécution (et lors de la compilation pour ce qui est vérifiable à ce moment là) et qu'ils soient pris en compte par les outils de génération de documentation type doxygen. A partir de ce moment il n'est plus nécessaire de les rajouter dans le cartouche de commentaires (tout comme ça fait bien longtemps que je ne met plus le nom des fonctions et des classes dans ce fameux commentaire).

---

Je suis d'accord avec le fait que le respect des préconditions doit être testé / testable dans le code.

Et je suis tout à fait d'accord avec le principe que le code devrait se suffire à lui meme (je défend ce point de vue depuis longtemps déjà). Mais je ne crois sincèrement pas que le code puisse être la seule source d'information dont dispose l'utilisateur d'une classe ou d'une fonction!

Ne serait-ce que parce que, dans certaines conditions (bibliothèque externe, par exemple), le code n'est pas forcément disponible, mais aussi parce que l'on ne peut décemment pas demander à l'utilisateur d'une classe ou d'une fonction de plonger dans le code pour savoir si la classe ou la fonction est adaptée à ses besoins, ou pour savoir comment l'utiliser.

D'une certaine manière, tout est fait pour que l'utilisateur n'ait pas à s'inquiéter de "ce qu'il y a sous le capot" lorsqu'il utilise une classe ou une fonction. C'est le but même de l'encapsulation des données. Il est totalement illogique de demander à l'utilisateur de s'intéresser au code pour savoir comment utiliser telle classe ou telle fonction! Cela contredit purement et simplement le principe d'encapsulation!

Pour palier ce conflit d'intérêts, on dispose d'une technique simple : la création d'un cartouche. Qu'il soit utilisé pour la génération automatique de documentation ou non n'a finalement que peu d'importance. Au pire, cela impliquera une mise en forme particulière. Mais le cartouche devrait à mon sens être obligatoire et préciser "tout ce qui est utile" à l'utilisation d'une fonction ou d'une classe. Cela comprend le fait d'indiquer explicitement les préconditions à respecter ;)

Citation:

---

Envoyé par koala01

Mais je ne crois sincèrement pas que le code puisse être la seule source d'information dont dispose l'utilisateur d'une classe ou d'une fonction!

---

Moi non plus. C'est bien pour ça que je disais que les outils, notamment la génération de documentation, devait être capable de le prendre en compte.
Mais c'est effectivement aussi vrai pour les EDI (complétion, coloration, affichage d'aide contextuel, ...), pour les outils d'analyse de code, etc.

Citation:

---

Envoyé par koala01

Ne serait-ce que parce que, dans certaines conditions (bibliothèque externe, par exemple), le code n'est pas forcément disponible, mais aussi parce que l'on ne peut décemment pas demander à l'utilisateur d'une classe ou d'une fonction de plonger dans le code pour savoir si la classe ou la fonction est adaptée à ses besoins, ou pour savoir comment l'utiliser.

---

Soit tu n'as absolument aucun accès au code et donc pas accès non plus aux commentaires et dans ce cas il faut se référer à la documentation généré peu importe qu'elle le soit depuis un commentaire ou un syntaxe particulière du langage.
Soit tu as suffisamment accès au code pour voir le commentaire (typiquement un fichier d'en-tête, d'import ou autre mécanisme du même type) et tu peux voir la précondition tout autant que le commentaire.

Citation:

---

Envoyé par koala01

D'une certaine manière, tout est fait pour que l'utilisateur n'ait pas à s'inquiéter de "ce qu'il y a sous le capot" lorsqu'il utilise une classe ou une fonction. C'est le but même de l'encapsulation des données. Il est totalement illogique de demander à l'utilisateur de s'intéresser au code pour savoir comment utiliser telle classe ou telle fonction! Cela contredit purement et simplement le principe d'encapsulation!

---

Là encore je suis d'accord. Mais la précondition ce n'est pas "sous le capot", c'est une part de l'interface publique. Donc l'utilisateur doit y avoir accès.

Citation:

---

Envoyé par koala01

Pour palier ce conflit d'intérêts, on dispose d'une technique simple : la création d'un cartouche. Qu'il soit utilisé pour la génération automatique de documentation ou non n'a finalement que peu d'importance. Au pire, cela impliquera une mise en forme particulière. Mais le cartouche devrait à mon sens être obligatoire et préciser "tout ce qui est utile" à l'utilisation d'une fonction ou d'une classe. Cela comprend le fait d'indiquer explicitement les préconditions à respecter ;)

---

Le problème que j'y vois c'est si tu l'indique dans un cartouche de commentaire (peu importe la mise en forme) et dans le code, tu te répètes avec le surcoût de travail et les risques d'incohérence que cela implique.
Alors que si tu ne l'exprime qu'une seule et unique fois, d'une manière qui reste lisible par un humain et que les outils le prenne en charge tu n'as pas ces inconvénients, tu n'as pas le souci de devoir plonger dans le code de ta fonction/classe et c'est tout benef.


J'ai la vague impression que tu penses que je préconise de ne pas écrire les pre/postconditions dans le cartouche et de mettre les contrôles dans le code de mes fonctions classes.
Mais pas du tout. En l'état actuel du C++, je décris les pre/postconditions dans mon cartouche de commentaires et je pense que c'est indispensable.
Mais ce que je souhaiterais c'est d'avoir un support plus natif des pre/postconditions qui remplacerais avantageusement à la fois les commentaires dans le cartouche et les vérifications dans le code. C'est à dire la possibilité de ne décrire qu'une seule et unique fois les pre/postconditions et qui soit aussi bien à destination de l'humain qu'à celle des outils.

Bref je préférerais largement pouvoir écrire (ne t'arrête pas aux détails de la syntaxe, c'est juste un exemple)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

/**  * Ce que fait ma fonction  *  * Les parametres et valeur de retour  */ @pre : mes preconditions qui sont pris en charge par le compilateur, la génération de doc et tous les outils @post : mes postconditions ... void foo();   void foo() { // Uniquement le code effectif }

---

plutôt que

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

/**  * Ce que fait ma fonction  *  * Les parametres et valeur de retour  *  * \pre : mes precondition qui sont pris en charge par lla génération de doc mais pas les autres outils  * \post : mes postcondition ...  */ void foo();   void foo() { // Et la je verifie en plus de faire le travail effectif }

---

Et la solution intermédiaire

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

/**  * Ce que fait ma fonction  *  * Les parametres et valeur de retour  *  * \pre : mes precondition qui sont pris en charge par lla génération de doc mais pas les autres outils  * \post : mes postcondition ...  */ @pre : mes preconditions qui sont pris en charge par le compilateur @post : mes postconditions ... void foo();   void foo() { // Uniquement le code effectif }

---

n'est pas non plus, à mon sens satisfaisante.

A la limite une syntaxe où la prise en charge des pre/postcondition n'apparait que dans les commentaires mais est pris en charge par tous les outils y compris le compilateur pour mettre en place les vérification pourrait éventuellement me convenir (même si ça me titillerais un peu) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

/**  * Ce que fait ma fonction  *  * Les parametres et valeur de retour  *  * \pre : mes precondition qui sont pris en charge par la génération de doc mais aussi par le compilateur et les autres outils  * \post : mes postcondition ...  */ void foo();   void foo() { // Uniquement le code effectif }

---

Pour préciser mon parallèle de tout à l'heure, je préfère largement :

Code:

---

1 2 3 4 5 6

/**  * Ce que fait ma fonction  *  * Les parametres et valeur de retour  */ void foo();

---

à

Code:

---

1 2 3 4 5 6 7 8

/**  * \fn void foo()  *  * Ce que fait ma fonction  *  * Les parametres et valeur de retour  */ void foo();

---

Qui n'apporte rien d'utile.



Après nous sommes d'accord que ça nécessite une évolution du langage et des outils. Et qu'actuellement il reste indispensable des les décrire dans le cartouche de commentaire.

Citation:

---

Envoyé par gl

Soit tu n'as absolument aucun accès au code et donc pas accès non plus aux commentaires et dans ce cas il faut se référer à la documentation généré peu importe qu'elle le soit depuis un commentaire ou un syntaxe particulière du langage.
Soit tu as suffisamment accès au code pour voir le commentaire (typiquement un fichier d'en-tête, d'import ou autre mécanisme du même type) et tu peux voir la précondition tout autant que le commentaire.

---

Sans oublier les cas hybrides, fréquent en C et en C++, où tu n'as accès qu'au fichier d'en-tête.

Citation:

---

Là encore je suis d'accord. Mais la précondition ce n'est pas "sous le capot", c'est une part de l'interface publique. Donc l'utilisateur doit y avoir accès.

---

Oui, la précondition devrait pouvoir être accessible, mais, dans la pratique, elle sera surtout testée soit à la compilation à l'aide d'un static_assert (par exemple), soit à l'exécution, à l'aide d'un assert.

Quoi qu'il en soit, il est difficile d'estimer que l'expression d'une précondition est réellement accessible à quelqu'un qui ne devrait pas avoir à s'intéresser à l'implémentation des différentes fonctions ;)

Citation:

---

Le problème que j'y vois c'est si tu l'indique dans un cartouche de commentaire (peu importe la mise en forme) et dans le code, tu te répètes avec le surcoût de travail et les risques d'incohérence que cela implique.

---

Dans l'absolu, je suis d'accord avec toi. C'est la raison pour laquelle je suis globalement opposé -- sauf cas particulier -- à l'utilisation de commentaires dans le code.

Mais, au meme titre que l'interface, les pré/post conditions font partie des choses particulièrement stables que l'on peut retrouver dans le code : Si tu les prends en compte, il n'y a aucune raison pour qu'elles ne soient plus prises en compte à l'occasion d'une refonte de ton code ;)

Citation:

---

J'ai la vague impression que tu penses que je préconise de ne pas écrire les pre/postconditions dans le cartouche et de mettre les contrôles dans le code de mes fonctions classes.
Mais pas du tout. En l'état actuel du C++, je décris les pre/postconditions dans mon cartouche de commentaires et je pense que c'est indispensable.
Mais ce que je souhaiterais c'est d'avoir un support plus natif des pre/postconditions qui remplacerais avantageusement à la fois les commentaires dans le cartouche et les vérifications dans le code. C'est à dire la possibilité de ne décrire qu'une seule et unique fois les pre/postconditions et qui soit aussi bien à destination de l'humain qu'à celle des outils.

Après nous sommes d'accord que ça nécessite une évolution du langage et des outils. Et qu'actuellement il reste indispensable des les décrire dans le cartouche de commentaire.

---

Au temps pour moi, j'avais effectivement cette impression.

Mais tu touche du doigt le réel problème : pour pouvoir y arriver, il faudrait déjà une très sérieuse évolution au niveau du langage, et, d'une certaine manière, cela ne pourrait sans doute arriver que pour ce qui est vérifiable de manière statique uniquement.

On dispose maintenant de static_assert qui joue plus ou moins le role, mais, comment s'assurer qu'une précondition de l'ordre "le tableau ne peut pas être vide" soit vérifiée à l'exécution :question:

Citation:

---

Envoyé par koala01

On dispose maintenant de static_assert qui joue plus ou moins le role, mais, comment s'assurer qu'une précondition de l'ordre "le tableau ne peut pas être vide" soit vérifiée à l'exécution :question:

---

En D, c'est vérifié (en Debug seulement) à grand coup de assert, c'est pas une mauvaise chose je trouve.
Il faudrait par contre (comme vous dites) que ce soit plus automatisé.

Dans la STL, il y à aussi énormément de vérifications avec des assert (toujours en Debug seulement).

Le problème, c'est que cela se passe au niveau du code, et, si j'ai bien compris ce que dit Gl (dis moi si je me trompe :D), c'est qu'il faut dupliquer cette information au niveau de la documentation, ou, si tu préfères, au niveau de ce qui est strictement accessible à l'utilisateur.

Bien sur que assert existe et c'est une bonne chose. Bien sur qu'il est utilisé, parfois sous utilisé, parfois sur utilisé (ou utilisé à mauvais escient), et ca, c'est à chaque développeur de faire son propre mea culpa ;). Mais il n'existe (apparemment dans aucun langage impératif) aucun mécanisme qui permette d'avoir à la fois "le beurre et l'argent du beurre" en ayant tout à la fois la valeur "documentaire" et la vérification à l'exécution des préconditions / postconditions.

D'une certaine manière, la notion de concept se rapproche de cette idée, mais, ils ont été abandonnés :aie:

Puisqu’on en parle (et qu’un peu d’auto pub ne fait pas de mal :mrgreen:), dans cet article, je décris notamment un moyen à l’aide de macros de retrouver ses pré/postconditions à la fois dans le code et dans la doc doxygen.

C’est ce que j’utilise personnellement. Ça a l’inconvénient que ça n’apparaît que dans doxygen, et pas dans l’en-tête de fichier. Mais comme gl, j’ai horreur de devoir me répéter : ça finit toujours par être incohérent.

Citation:

---

Envoyé par koala01

Mais il n'existe (apparemment dans aucun langage impératif) aucun mécanisme qui permette d'avoir à la fois "le beurre et l'argent du beurre" en ayant tout à la fois la valeur "documentaire" et la vérification à l'exécution des préconditions / postconditions.

---

Il y a vraiment ça en Eiffel, pour le coup. Comme c’est intégré au langage, ça a la même valeur documentaire que la signature de la fonction.

Pour D, j’ai regardé rapidement, je trouve leur façon de faire bizarre et peu élégante du point de vue des termes choisis (assert ne signifie pas du tout la même chose que require) et de la syntaxe.

Citation:

---

Envoyé par koala01

Le problème, c'est que cela se passe au niveau du code, et, si j'ai bien compris ce que dit Gl (dis moi si je me trompe :D), c'est qu'il faut dupliquer cette information au niveau de la documentation, ou, si tu préfères, au niveau de ce qui est strictement accessible à l'utilisateur.

---

Oui assert() c'est au niveau du code, et c'est bien une des limitations d'assert (les autres étant qu'il ne distingue pas précondition, postcondition et invariant et que c'est purement au runtime).

Mais si tu disposes dans le langage des mots-clé nécessaires et des mécanismes correspondants, ce n'est plus à l'intérieur de ton implémentation et ce n'est pas "simplement du code" (et tout cas pas plus que la signature de fonction), ce qui permet :

• A la génération de doc de les prendre en compte.
• Aux IDE de le présenter dans l'aide contextuel.
• A un humain de le lire au même titre qu'il lit le cartouche de commentaires et la signature de fonction.
• Aux compilos de tester à la compilation ce qui est statiquement vérifiable et de générer en debug le code nécessaire à vérifier le reste (en gros de générer des assert et static_assert pour vérifier toutes ces conditions).
• Aux outils de vérification de code de lever ou pas certaines alertes.
• De ne pas avoir à se répéter (avec les risques que cela induit).

Citation:

---

Envoyé par koala01

Bien sur que assert existe et c'est une bonne chose. Bien sur qu'il est utilisé, parfois sous utilisé, parfois sur utilisé (ou utilisé à mauvais escient), et ca, c'est à chaque développeur de faire son propre mea culpa ;). Mais il n'existe (apparemment dans aucun langage impératif) aucun mécanisme qui permette d'avoir à la fois "le beurre et l'argent du beurre" en ayant tout à la fois la valeur "documentaire" et la vérification à l'exécution des préconditions / postconditions.

---

Comme le signale white_tentacle, on peut regarder du côté de D et de Eiffel (de toute manière dès que l'on parle de ppc, il faut regarder du côté de Eiffel).

Citation:

---

Envoyé par koala01

D'une certaine manière, la notion de concept se rapproche de cette idée, mais, ils ont été abandonnés :aie:

---

Remis à une date ultérieur et sous une forme différente plutôt me semble-t-il.
C'est proche mais l'idée des concepts est plutôt de fournir l'interface (au sens structure et services rendus) que doit satisfaire un paramètre template.

Citation:

---

Envoyé par koala01

Le problème, c'est que cela se passe au niveau du code, et, si j'ai bien compris ce que dit Gl (dis moi si je me trompe :D), c'est qu'il faut dupliquer cette information au niveau de la documentation, ou, si tu préfères, au niveau de ce qui est strictement accessible à l'utilisateur.

---

C'est pour ça que je parlais du D, où l'on peut retrouver des choses du genre (cf doc)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

long square_root(long x) in { assert(x >= 0); } out (result) { assert((result * result) <= x && (result+1) * (result+1) >= x); } body { return cast(long)std.math.sqrt(cast(real)x); }

---

ou encore

Code:

---

1 2 3 4 5 6 7 8 9 10

class Date { int day; int hour;   invariant() { assert(1 <= day && day <= 31); assert(0 <= hour && hour < 24); } }

---

(Bon la syntaxe, on aime ou pas, c'est pas très important)

Mais quelque chose du genre permet d'avoir les pré/post conditions testées dans le code et d'avoir un moyen de générer de la doc qui en tient compte.