Restreindre le paramètre d'un Template via Heritage

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:

---

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

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

Code:

---

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'

Merci,

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

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

Salut, et bienvenue sur le forum.

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

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 :P

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 :question:

Ensuite, je présumes (peut être à tord :aie:... 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 :D) 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 :aie:

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

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

Tu pourrais peut être envisager l'utilisation de traits de politiques.

Si tu crées une structure proche de

Code:

---

1 2	template <typename> struct MyTrait;

---

Que tu la spécialise uniquement pour les type compatibles sous la forme de

Code:

---

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

template <> struct MyTrait<size_t> { typedef size_t value_type; typedef size_t & reference_type; typedef size_t * pointer_type; typedef size_t const const_type; typedef size_t volatile volatile_type; }; template <> struct MyTrait<double> { typedef double value_type; typedef double & reference_type; typedef double * pointer_type; typedef double const const_type; typedef double volatile volatile_type; };

---

et que tu ne la spécialise pas pour les autres types primitifs

il peut te suffire d'écrire ta classe sous la forme de

Code:

---

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

template <typename T /* les autres arguments template */> class MyClass { public: typedef MyTrait<T>::value_type value_type; typedef MyTrait<T>::reference& reference_type; typedef MyTrait<T>::pointer_type * pointer_type; typedef MyTrait<T>::const_type const const_type; typedef MyTrait<T>::volatile_type volatile volatile_type; /* la suite */   };

---

tu auras la certitude d'obtenir une erreur de compilation si tu fournis à MyClass autre chose qu'un size_t ou qu'un double (selon l'exemple que je donne) au motif que "MyTrait<T>::value_type n'est pas déclaré" (avec T : le type choisi)", et de même pour les autres.

Simple et efficace :D

Tu n'auras même plus à recourir à l'héritage multiple ou à l'héritage virtuel: tout ce que tu devra faire, c'est t'assurer que le trait de politique fass partie des arguments template ;)

Merci,
Il s'agit en effet d'une methode interessante!
Je reste cependant un peu sceptique :
J'utilise de nombreux types et cette methode restreint si j'ai bien compris le panel de types utilisables.
Mais est-ce que je suis assuré que le trait X ets utilise dans
la methode A et le traits Y dans la methode B et pas l'inverse ?

Citation:

---

Envoyé par SamAgace

Merci,
Il s'agit en effet d'une methode interessante!
Je reste cependant un peu sceptique :
J'utilise de nombreux types et cette methode restreint si j'ai bien compris le panel de types utilisables.

---

Absolument pas...

A vrai dire, MyClass peut parfaitement suffire en l'état, et être renommée, afiin de prendre une valeur documentée en PrimitiveCheck:
template <typename T>

Code:

---

1 2 3 4 5 6 7 8

struct PrimitiveCheck { typedef MyTrait<T>::value_type value_type; typedef MyTrait<T>::reference& reference_type; typedef MyTrait<T>::pointer_type * pointer_type; typedef MyTrait<T>::const_type const const_type; typedef MyTrait<T>::volatile_type volatile volatile_type; };

---

La seule chose que tu auras à faire, c'est de fournir un type primitif qui sera vérifié par cette classe.

Ce sera d'autant plus nécessaire que, si tu veux pouvoir choisir le type primitif, il faudra bien que... tu dispose de value_type (essentiellement).

Tu peux donc parfaitement avoir une classe, qui utilise au choix des doubles ou des int et un autre argument template, qui prendrait la forme de

Code:

---

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

template <typename primitive, class Type> class AClass { public: /* on s'assure qu'elle n'utilise que des int ou des doubles   * Comme on doit pouvoir utiliser le type double ou le type int dans   * nos fonctions, on va le nommer "primitive_type"   */ typedef typename PrimitiveCheck::value_type primitive_type; //check intégré :D void foo(primitive_type v) { /*ce qui doit être fait */ }   };

---

Citation:

---

Mais est-ce que je suis assuré que le trait X ets utilise dans
la methode A et le traits Y dans la methode B et pas l'inverse ?

---

Si tu sais que tu veux un type bien particulier pour un paramètre, il te suffit de l'indiquer explicitement :D

Code:

---

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

template <class Type> class MyClass { public: void intFoo(size_t i) { } void doubleFoo(double d) { } };

---

Ok
Malgres tout il reste des choses a peaufiner mais je pense que la piste que tu m'as donné est intéressante.
Merci beaucoup, je clos le topic!

Samagace

Nous sommes évidemment d'accord que le typedef que tu choisira de créer correpondra... à tes besoins, hein:question:

Si tu as, cela peut arriver, explicitement besoin d'un pointeur sur entier, tu créera un typedef sur... PrimitiveCheck<T>::pointer_type ;)