Difficile de trouver un bon titre pour cette question. Ce dont j'ai réellement besoin, c'est de pouvoir fournir des paramètres de gabarit avec un nombre différent d'arguments à la place d'un seul paramètre. Ne fait pas beaucoup de sens, donc je vais aller sur la raison:Conception basée sur des règles et valeurs par défaut
template < typename T, template <typename,typename> class Policy = default_policy >
struct policy_based : Policy<T, policy_based<T,Policy> >
{
// inherits R Policy::fun(arg0, arg1, arg2,...,argn)
};
// normal use:
policy_base<type_a> instance;
// abnormal use:
template < typename PolicyBased > // No T since T is always the same when you use this
struct custom_policy {};
policy_base<type_b,custom_policy> instance;
L'affaire est que pour beaucoup anormal utilise la politique sera basé sur un seul type T, et ne peut pas vraiment être paramétrées sur T, cela n'a aucun sens de prendre T comme paramètre. Pour d'autres utilisations, y compris la valeur par défaut, une politique peut avoir du sens avec n'importe quel T.
J'ai quelques idées mais aucune d'elles n'est vraiment favorite. Je pensais que j'avais une meilleure réponse - en utilisant la composition au lieu de politiques - mais ensuite je me suis rendu compte que cette affaire avait besoin d'informations supplémentaires que la classe elle-même n'aurait pas. C'est comme la troisième fois que j'ai refaçonné cette construction stupide et j'en ai quelques versions personnalisées que j'essaie de consolider. Je voudrais obtenir quelque chose cloué cette fois plutôt que de simplement pêcher et espérer que cela fonctionne cette fois. Donc, je suis en train de pêcher des idées en ce moment en espérant que quelqu'un a quelque chose que je serai tellement impressionné par cela que je vais changer de divinités. Quelqu'un a une bonne idée? Editer: Vous vous demandez peut-être pourquoi je ne récupère pas simplement T de la définition de politique basée sur le modèle pour default_policy. La raison en est que default_policy est vraiment spécialisé pour certains types T. Depuis que j'ai posé la question, j'ai trouvé quelque chose qui peut être ce dont j'ai besoin, ce qui va suivre, mais je pourrais encore utiliser d'autres idées.
template < typename T >
struct default_policy;
template < typename T, template <typename> class Policy = default_policy >
struct test : Policy<test<T,Policy>>
{};
template < typename T >
struct default_policy< test<T, default_policy> >
{
void f() {}
};
template < >
struct default_policy< test<int, default_policy> >
{
void f(int) {}
};
Edit: déconner encore avec elle. Je n'étais pas trop friand de ce qui précède car il fait en sorte que default_policy est couplé en permanence à "test" et ne peut donc pas être réutilisé dans une autre méthode, comme avec plusieurs modèles comme suggéré ci-dessous. Il ne s'échelonne pas du tout et nécessite une liste de paramètres au moins aussi longue que "test". Essayé quelques approches différentes qui ont échoué jusqu'à ce que je trouve une autre qui semble fonctionner jusqu'à présent:
template < typename T >
struct default_policy;
template < typename T, template <typename> class Policy = default_policy >
struct test : Policy<test<T,Policy>>
{};
template < typename PolicyBased >
struct fetch_t;
template < typename PolicyBased, typename T > struct default_policy_base;
template < typename PolicyBased >
struct default_policy : default_policy_base<PolicyBased, typename fetch_t<PolicyBased>::type> {};
template < typename T, template <typename> class Policy >
struct fetch_t< test<T,Policy> > { typedef T type; };
template < typename PolicyBased, typename T >
struct default_policy_base
{
void f() {}
};
template < typename PolicyBased >
struct default_policy_base<PolicyBased,int>
{
void f(int) {}
};
Initialement, je n'aime pas l'idée des déclarations multiples puisque le but de ceci est de consolider beaucoup d'objets similaires mais légèrement différents pour partager du code. Avec un classement de base correct, bien que la plupart des trucs copier/coller puissent être retirés; Je devrais tirer plus haut que prévu initialement mais ... L'idée de twoArgs est aussi intéressante et pourrait l'être davantage si les paramètres nommés étaient considérés. Merci. +1 –