restriction sur une classe template

Version imprimable

Voir 40 message(s) de cette discussion en une page

voici le "toy" code suivant:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 template< int n=2> struct C{ int F () {return -n;} }; template< int n=2> struct A{ int F () {return n;} }; template< int n=2> struct B:public A<n>{ int F () {return n+1;} }; template< class T> struct H{ int h () { T a; return a.F();} }; int main() { H<A<> > u_a; H<B<> > u_b; H<C<> > u_c; int a = u_a.h(); int b = u_b.h(); int c = u_c.h(); return 0; }
je souhaiterai, si c'est possible, qu ' à la compiliation l'instantiation
Code:

1 2 3 H<C<> > u_c; int c = u_c.h();
envoie une erreur.

Le but est de restreindre la portée de l 'argument template de H pour seule les classes dérivées de A soient permises et cela sans toucher aux classes A,B ou C.

Merci encore
Mathieu

01/10/2009, 08h53
Alp

Je te conseille de regarder du côté de boost.type_traits, en particulier :
http://www.boost.org/doc/libs/1_40_0...s_base_of.html
Il te suffit d'utiliser is_base_of<A, ton_paramètre_template>::value dans un endroit qui provoque une erreur de compilation si ça évalue à false. Typiquement : char foo[is_base_of<A, T>::value ? 1 : -1];
Ou plus simple, un BOOST_STATIC_ASSERT ou similaire.
01/10/2009, 09h09
Math75

Je viens de regarder ta proposition.
Il n'y a donc pas une synthaxe c++ qui empèche certaines instantiations.
Il faut avoir recours à Boosts ,que je ne peux pas insérer dans ma librairie de travail :cry:

Au secours!:(

Sinon, tu as des petits hacks si tu veux détecter ce genre de choses à la compilation.

Je verrais bien, par exemple, quelque chose de ce genre (à vérifier, mais l'idée est là) :
Code:

1 2 3 4 5 6 7 8 9 10 11 struct true_type { char c; } struct false_type { }; true_type f(const A& a) { return true_type(); } template <typename t> false_type f(const T& t) { return false_type(); } // ... dans H< T > char foo[sizeof(f(T()) != sizeof(false_type) ? 1 : -1];
Quelque chose de ce genre en tout cas. Je devrais pouvoir mieux t'éclairer d'ici 2 ou 3 cafés...

01/10/2009, 09h41
Math75

ok j attends l effet de la caféine alors. Si tu veux aller plus vite, prends du guarana ou emphetamine, c est assez efficace aussi :D

Un Kfé bien serré :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
template< int n=2> 
struct C{
 
	int F () {return -n;}
};
 
 
template< int n=2> 
struct A{
	int F () {return n;}
};
 
template< int n=2> 
struct B:public A<n>{
 
	int F () {return n+1;}
};
 
 
struct true_type { char c; };
struct false_type {true_type t[2]; };// je préfère faire dépendre de true_type pour être sur qu'ils ont vraiment une taille différente
 
template<int n> true_type f_check(A<n>const&);
false_type f_check(...);
 
template<bool ,class> struct enable_if;
template<class T> struct enable_if<true,T>{typedef T type;};
 
template< class T> 
struct H{
   typedef typename enable_if<(sizeof(f_check(T()))== sizeof(true_type)),T>::type check_type;
	int h () {
      T a; return a.F();
   }
};
 
int main()
{
	H<A<> > u_a;
	H<B<> > u_b;
	H<C<> > u_c;   
   u_a.h();
   u_b.h();
   u_c.h();
 
	return 0;
}

Il existe __is_base_of( base , derived) qui est du Visual spécifique mais que je ne vois pas trop comment appliquer avec une classe de base template sans connaître les paramètres génériques utilisés pour l'héritage.

01/10/2009, 10h20
Goten

La même que 3Darchi pour moi, le tout bien encapsulé dans une structure, histoire de cacher les détails d'implémentation.
Y'a juste le coup du T(), si le type n'est pas default-constructible c'est fichu, donc je préfère passer par une fonction helper (juste la signature, on se fiche de la définition ;

Code:

T makeT(); // pas la peine de la définir puisqu'elle sera juste évalué par sizeof().
01/10/2009, 10h21
3DArchi

Citation:

Envoyé par Goten

Y'a juste le coup du T(), si le type n'est pas default-constructible c'est fichu, donc je préfère passer par une fonction helper (juste la signature, on se fiche de la définition ;

Code:

T makeT(); // pas la peine de la définir puisqu'elle sera juste évalué par sizeof().

:ccool: bien vu
01/10/2009, 10h31
Alp

Citation:

Envoyé par 3DArchi

Un Kfé bien serré

Volontier :mrgreen:

Citation:

Envoyé par Goten

La même que 3Darchi pour moi, le tout bien encapsulé dans une structure, histoire de cacher les détails d'implémentation.
Y'a juste le coup du T(), si le type n'est pas default-constructible c'est fichu, donc je préfère passer par une fonction helper (juste la signature, on se fiche de la définition ;

Code:

T makeT(); // pas la peine de la définir puisqu'elle sera juste évalué par sizeof().

Joli, effectivement :)
J'en étais arrivé à quelque chose de similaire également.

Donc pour Mathieu, l'idée, en gros, c'est que tu dois reporter toutes les vérifications & compagnie de l'exécution à la compilation.
En particulier, ici, ce qui permet de décider, c'est qu'on a 2 fonctions, enfin une fonction qui a 2 surcharges. La première prend un const A&, et donc n'importe laquelle de ses filles. L'autre on s'en fout. La première retourne quelque chose de type true_type, une structure qui n'est pas vide, d'une certaine taille. La seconde false_type, qui a une taille différente de true_type. Tout ça permet le moment venu, de voir la taille de l'objet qui sera retourné par un appel à check, appliqué à n'importe quelle valeur de type T (cf la fonction de Goten). Le mécanisme de résolution des surcharges des compilateurs C++ choisira celle qui prend un const A& si T est A ou une de ses classes filles, sinon il appellera l'autre. Comme les tailles sont différentes, si sizeof(check(makeT())) == sizeof(true_type), alors T hérite de A, ou est A. Sinon, ce n'est pas le cas, et tu peux lancer d'une façon ou d'une autre une erreur de compilation.
01/10/2009, 11h10
Math75
C est vraiement de la haute voltige.
Il y a cependant des choses que je ne comprends pas bien:
Code:

1 2 false_type f_check(...);
c est un sucharge de la fonction libre f_check qui pour un nombre quelconque d'argument hormis const A<n> & renvoie un false_type a savoir un char[2].

de même en retirant le mot clef typename de
Code:

1 2 typedef typename enable_if<(sizeof(f_check(T()))== sizeof(true_type)),T>::type check_type;
je provoque une erreur C4346. Si j ai bien compris pour de raison du standard du nouveau compilo, on doit préciser check_type est bien un type?
Merci Messieurs, vous êtes superbes!
01/10/2009, 11h14
Goten

C'est quoi la première question? (sur la surcharge)

Pour typename : Non c'est pour indiquer au compilo que ::type est un type.
01/10/2009, 11h14
3DArchi

En gros, cela se base sur le SFINAE.
Aucune de ces fonctions n'est instanciée.
Elles servent juste à provoquer des erreurs de compilation si cela ne colle pas bien.
[EDIT] : pour typename : F.A.Q. :A quoi sert le mot-clé typename ?
01/10/2009, 11h15
Alp
Citation:
Envoyé par Math75

C est vraiement de la haute voltige.
Il y a cependant des choses que je ne comprends pas bien:

Code:

1 2 false_type f_check(...);

c est un sucharge de la fonction libre f_check qui pour un nombre quelconque d'argument hormis const A<n> & renvoie un false_type a savoir un char[2].
Bah, si tu lui passes un const A<n>&, il va prendre la première, pas celle là. Donc c'est cette fonction qui sera choisie si le type passé ne fait pas partie de la hiérarchie de A (A et ses classes filles).

Mais sinon, oui, c'est une surcharge.

Citation:

Envoyé par Math75

je provoque une erreur C4346. Si j ai bien compris pour de raison du standard du nouveau compilo, on doit préciser check_type est bien un type?
Merci Messieurs, vous êtes superbes!

Tu dois préciser que enable_if<(sizeof(f_check(T()))== sizeof(true_type)),T>::type est bien un type. Ca pourrait tout aussi bien être une valeur statique ou enum.
01/10/2009, 11h16
Goten

@3Darchi : hum, ça se base sur la sélection des fonctions surchargé, mais là je vois pas de SFINAE?
01/10/2009, 11h18
3DArchi

Citation:

Envoyé par Goten

@3Darchi : hum, ça se base sur la sélection des fonctions surchargé, mais là je vois pas de SFINAE?

J'ai parlé trop vite.:oops:
[EDIT] : faut vraiment que j'aille me le chercher ce café.
01/10/2009, 11h19
Alp

Disons que c'est similaire à SFINAE. SFINAE c'est la même chose, sauf que c'est pour détecter l'interface d'une classe : présence d'une fonction foo, d'un membre machin, etc. Mais c'est la même idée puisque comme tu le dis on joue sur la résolution des surcharges (oui, en fait, on manipule ouvertement et sans honte le compilateur).
01/10/2009, 11h22
Goten

Hum, là par contre je te suis pas.

Citation:

sauf que c'est pour détecter l'interface d'une classe : présence d'une fonction foo, d'un membre machin

Ca c'est une application de SFINAE. Après tout SFINAE c'est qu'un mécanisme du compilo on en fait 'ce qu'on veut'.
Bref toujours est-il que SFINAE s'applique quand t'as des templates, si la substitution du type n'est pas compatible, ça mène pas a une erreur. Là c'est juste de la sélection de fonction par 'affinité'.
01/10/2009, 11h26
Math75

Merci pour tout.
Mathieu
01/10/2009, 11h27
3DArchi

Citation:

Envoyé par Goten

Hum, là par contre je te suis pas.

Ca c'est une application de SFINAE. Après tout SFINAE c'est qu'un mécanisme du compilo on en fait 'ce qu'on veut'.
Bref toujours est-il que SFINAE s'applique quand t'as des templates, si la substitution du type n'est pas compatible, ça mène pas a une erreur. Là c'est juste de la sélection de fonction par 'affinité'.

et le fait que ... est le moins fort dans la sélection.
Ce que veux dire Alp à mon avis et ce qui m'avait aussi fait parler trop vite, c'est que dans les 2 cas on a un schéma de comportement du compilo similaire : il essaie un truc et si ça marche pas il essaie le suivant sans râler. Mais dans le fond, effectivement, ce n'est pas tout à fait la même chose.
01/10/2009, 11h34
Goten

Ah oui en effet, on peut faire un parallèle, je vois le truc maintenant. Si la première surcharge ne convient pas il passe à la seconde. oki d'oki =)

Voir 40 message(s) de cette discussion en une page