Templates : restreindre l'instanciation à une hiérarchie de types

Hello,

Disons que j'ai :

Code:

---

1 2 3 4 5

template<typename T> class tempClass { ... };

---

Comment faire en sorte que tempClass ne soit instanciable qu'avec des types descendant du même parent (avec le parent lui-même), la hiérarchie étant construite via CRTP ?...

Merci.

Corrigez moi si je me trompe, mais a tu regarde du cote de <type_traits> avec std/boost::is_base_of<Base, Derived>?

Edit : Le tout couple avec une static_assert

Doc boost de la classe, je me souvenais plus de l'odre des template! http://www.boost.org/doc/libs/1_48_0...s_base_of.html

Bonjour,

ne serait-pas possible en déclarant ça comme abstraite et en implémentant que pour les types spécifiques nécessaires ?

Exemple de ce que j'ai en tête:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

template< class T > class tempClass { void doSomething()=0; }; class Parent {}; template<> class tempClass<Parent> { void doSomething() {} };

---

Ce qui, si ça fonctionne comme je l'espère, entraînera une erreur de compilation avec autre chose qu'un Parent (ou dérivé), avec une errreur de "cannot instatiate abstract class".

Bonjour,

Pour cette dernière proposition, je crains fort que l'erreur de compilation survienne même avec les classe dérivées de « Parent »...

+1 à la réponse de victor_gasgas ; j'ajoute que les type traits ayant été intégré au TR1, il n'est pas nécessaire d'utiliser boost ou C++11 pour y avoir accès.

Par contre, static_assert nécessite boost ou C++11 (mais on peut faire sans).

Code:

---

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

template <class C, class P = Parent, bool defined = std::is_base_of<P,C> > class tempClass;   template <class C, class P = Parent> class tempClass<C,P,true> { // ... le code de la classe }   // pas de définition pour tempClass<C,P,false>, ce qui va provoquer // une erreur à la compilation si C ne dérive pas de P.

---

Ou quelque chose dans le style :)

Comment dois-je interpréter l'absence d'implémentation avec ta première déclaration de template ?

Salut,

Citation:

---

Envoyé par oodini

Comment dois-je interpréter l'absence d'implémentation avec ta première déclaration de template ?

---

Justement, comme une déclaration de la classe template, et non comme sa définition :D

On pourrait, en gros, dire qu'il s'agit d'une déclaration anticipée (en tout cas, c'est le terme connu qui s'en rapproche le plus :D ) permettant au compilateur de savoir que ta classe fonctionne avec "jusqu'à" trois paramètres template (les deux derniers ayant des type par défaut ;).

Mets toi un instant à la place du compilateur, tu vas voir, le jeu est sympa :D

En ligne 1 et 2, le compilateur apprend qu'il existe une classe nommée tempClass qui est une classe template prenant trois arguments, dont les deux derniers sont factulatifs (car on donne une valeur par défaut).

Les arguments facultatifs disent que P est, à défaut d'indication contraire, de type Parent et que defined (le booléen) prend la constante renvoyée par is_base_of(P, C), c'est à dire true si la classe P est bel et bien d'un type de base de la classe C.

Les lignes 5 à 9 fournissent une définition pour cette tempClass pour certains arguments template particulier, dont le fait que le booléen (defined ;)) vaut true, c'est à dire si le résultat de l'évaluation de is_base_of est bel et bien true ;)

De cette manière, si on vient à avoir un code proche de

Code:

---

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

class A { /* ...*/ }; class B : public A { /* ...*/ };   int main() { tempClass<B, A> temp; }

---

is_base_of fournit bel et bien la constante true, vu que A est bien... la classe parent de B, et le compilateur trouve la définition de la classe correspondant à C = B, P = A, defined = true, et va donc l'utiliser (il n'y aura pas d'erreur de compilation :D )

Par contre, si tu utilise le code

Code:

---

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

class A { /* ...*/ }; /* !! pas d'héritage publique de A !!! */ class B { /* ...*/ };   int main() { tempClass<B, A> temp; }

---

Le compilateur trouve la déclaration de la classe template qui fonctionne avec les arguments fournis : C = B, P = A, defined = false.

Jusque là, il est content :D

Sauf que, quand il va rechercher le constructeur (par défaut ici :D ) de tempClass, il ne va pas le trouver, vu que la seule défintion qu'il trouve (et donc pour laquelle il existe bel et bien un constructeur par défaut (dans le cas présent) correspond aux argument C = B, P = A, defined = true, et que defined vaut... false :aie:

Il va donc sortir avec une erreur de compilation proche de

Code:

---

1 2	cannot find tempClass<C, P, defined>::tempClass() [with C = B, P = A, defined = false ]

---

Et c'est exactement ce que tu voulais : tempClass ne peut pas être utilisée si tu ne fournis pas effectivement une classe dérivée et sa classe mère (ou ancêtre) ;) :D

Effectivement, merci, je comprend bien ce qu'il se passe à présent.

Toutefois, le message n'est pas très clair, et un static_assert serait en effet bienvenu. :-)

Citation:

---

Envoyé par oodini

Effectivement, merci, je comprend bien ce qu'il se passe à présent.

Toutefois, le message n'est pas très clair, et un static_assert serait en effet bienvenu. :-)

---

Ben, oui, c'est le but du static_assert, parce que si, ici, on a encore un message *relativement* clair, mais, quand c'est une instanciation d'une classe template instanciée depuis une classe template instanciée depuis une classe template, il devient vachement difficile de retrouver le message original :aie:...

Le problème, c'est que le static_assert nécessite soit boost soit C++11 re :aie: :D

Citation:

---

Envoyé par koala01

Le problème, c'est que le static_assert nécessite soit boost soit C++11 re :aie: :D

---

Ça tombe bien, ce nouveau projet est en C++11. :)

Sans revenir sur la manière de parvenir à ce résultat, j'ai de gros doutes quand je vois ce genre de code : Y a-t-il vraiment une bonne raison de contraindre de manière si forte le template ("dériver de" est bien la contrainte la plus forte qui puisse exister) ?

L'un des intérêts des templates est justement qu'ils peuvent "tomber en marche" avec des types qui n'ont pas été prévus spécifiquement pour ça à l'origine, modulo quelques ajustements.

De mémoire, quand on bossait sur une version concepts de la biblitohèque standard, qui consistait justement à mettre en place des contraintes explicite sur les types acceptables par tel ou tel template, pas une seule fois sur l'ensemble de la bibliothèque standard il n'a été envisagé de mettre en place une contrainte "le type doit dériver de".

Nous n'avons pas d'information sur le but poursuivi par l'OP, qui avait une question orientée technique. Peut-être que ça peut parfois servir à renforcer la sémantique de la classe template: l'associer à un type tartempion qui se trouve avoir une fonction avec la bonne signature peut éventuellement être dépourvu de sens même si ça marche techniquement.
Autre point de vue plus technique (même si je t'accorde que pour le coup on pourrait voir ça comme trop restrictif): obliger à faire dériver le type paramètre d'une classe abstraite définissant l'interface attendue pourrait être une manière de documenter l'interface en question.

Citation:

---

Envoyé par therwald

Nous n'avons pas d'information sur le but poursuivi par l'OP, qui avait une question orientée technique. Peut-être que ça peut parfois servir à renforcer la sémantique de la classe template: l'associer à un type tartempion qui se trouve avoir une fonction avec la bonne signature peut éventuellement être dépourvu de sens même si ça marche techniquement.

---

On a rarement a faire ca. Si tel couplage devait exister et qu'il retrouve implanté comme ca, c'ets que le design a foiré a un moment.

Il y a vraiment peu d'instances ou on a besoin d'une telle surspecification de template et lorsqu'il y en a besoin, mieux vaut changer ses parametres afin d'avoir un type template plus contraints au niveau de la definition.