Discussion :

[SamAgace]

Bonjour à tous,

depuis quelques temps, je rencontre le problème suivant :

Je dois mettre en place une classe qu'on va appeler ALGO qui utilise un template classe A :

Code :

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

1
2
3
4
5
6
7
8
 
template <class A>
class ALGO {
private:
  A m_attribut;
public:
 /* ... */
};

Ce que je souhaite faire c'est limité l'utilisation du paramètre template "class A" à des classes héritant d'une classe virtuelle C.

Quelqu'un saurait-il comment faire ?

Merci d'avance.


Samagace

[omc24]

Bonjour,
Tu peux utiliser les Static Assert de Boost, par exemple dans le constructeur de ta classe

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
#include <boost/type_traits.hpp>
#include <boost/static_assert.hpp> 
#include "C.hpp"
...
...
template<class A>
ALGO<A>::ALGO()
{
  BOOST_STATIC_ASSERT((boost::is_base_of<C, A>::value));
}

Si A n'est pas une classe fille de C tu auras une erreur de compil'

[SamAgace]

Merci,

je ne savais qu'il existait ça dans BOOST, mais il n'y a aucun moyen de faire cela nativement en C++ ?

[omc24]

Il doit certainement exister des solutions, mais je ne vois pas...

[koala01]

Salut, et bienvenue sur le forum.

D'abord, la question qui tue: "pourquoi voudrais tu poser cette limitation ".

Je la justifie quand même un peu: typiquement, le but de la programmation générique est de... laisser le plus grand choix possible quant à l'utilisation que l'on pourra faire des fonctions et des classes template

Qui te dit que tu n'auras pas un utilisateur farfelu qui arrivera avec une classe compatible du point de vue de l'interface avec ta classe de base et qui voudra (à juste titre) utiliser ta classe template

Ensuite, je présumes (peut être à tord ... n'hésite pas à me dire que je me trompes ) que ton problème est en fait surtout de t'assurer que les objets réellement passés disposeront d'une interface particulière...

Mais là, tu peux être rassuré: tout type n'exposant pas l'interface à laquelle tu espères avoir accès dans ta classe provoquera irrémédiablement une erreur de compilation sous prétexte que telle ou telle fonction, tel ou tel type imbriqué est indisponible.

Bon, d'accord, l'erreur est parfois cryptique... Mais elle sera de toutes manière présente.

En outre, il faut savoir que, quoi qu'il arrive, ta classe template telle que tu la présente aura pour résultat de faire appartenir ALGO<derivee1> et ALGO<derivee2> à deux hiérarchies de classe différentes, même si derivee1 et derivee2 hérite, de manière directe ou indirecte, de manière virtuelle ou non, d'une classe commune...

Si tu veux qu'il en aille autrement, il y aura sans doute des mesures à prendre

Enfin, mais ce n'est qu'un détail: C++ autorise l'héritage virtuel afin de résoudre le problème de l'héritage en diamant, mais le seul fait de se retrouver dans une telle situation révèle souvent (parce que ce n'est pas toujours le cas ) un problème de conception sous-jasent, induit entre autre par une décision inopportune d'utiliser l'héritage, décision qui aurait sans doute été écartée si tu avais correctement appliqué le principe de substitution de Liskov

Je ne dis pas que c'est ton cas car je n'en connais pas assez sur ton projet pour l'affirmer, mais je fais cette mise en garde de manière générale pour, éventuellement, t'inciter à revoir ta conception

[SamAgace]

Bonjour et merci pour l'accueil !

Pour preciser davantage la raison de cette restriction j'ai simplement trouve plus propre d'imposer une interface afin de massurer que les bons types et arguments sont utilisés.
En effet si par exemple l'utilisateur utilise des unsigned int la ou j'attend des int ou des doubles, ou même d'autres types "compatibles" lors de la compil, le comportement ne pourra etre certifie comme correct.
D'où mon idée, surement un brin barbare, de contraindre qqchose qui par sa conception permet de lever des contraintres.
Je reste cependant ouvert a toute autre siggestion.


Samagace