Discussion :

[Rafiki3931]

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 :

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

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

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

Code :

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

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,

[white_tentacle]

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.

[oodini]

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

[Iradrille]

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 :

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

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

[Rafiki3931]

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 !

[Rafiki3931]

Merci Iradrille pour ta réponse.

[white_tentacle]

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 , 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.

[Rafiki3931]

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

Merci à tous pour votre participation.

[Jean-Marc.Bourguet]

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.

[oodini]

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.

[Jean-Marc.Bourguet]

À 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.

[oodini]

OK, au temps pour moi.

[koala01]

Salut,

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.

Tu as parfaitement raison sur ce point , 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 ) 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

[gl]

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).

[koala01]

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

[gl]

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.

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.

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.

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 :

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

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 :

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

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 :

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

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 :

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

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 :

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

1
2
3
4
5
6
/**
 * Ce que fait ma fonction
 *
 * Les parametres et valeur de retour
 */
void foo();

à

Code :

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

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.

[koala01]

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.

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

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

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

[Iradrille]

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

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).

[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 ), 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

[white_tentacle]

Puisqu’on en parle (et qu’un peu d’auto pub ne fait pas de mal ), 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.