Factory générique avec/sans variadic templates

Bonjour!

Tout d'abord, le code:

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

template< class Obj, class Key, typename Creator > class Factory { protected: typedef std::shared_ptr< Obj > ObjPtr; typedef std::map< Key, Creator > ObjMap;   public: Factory() {} virtual ~Factory() {} void Register( Key const & p_key, Creator p_creator ) { m_registered.insert( std::make_pair( p_key, p_creator ) ); } #if HAS_VARIADIC_TEMPLATES template< typename ... Parameters > ObjPtr Create( Key const & p_key, Parameters && ... p_params ) { ObjPtr l_return; typename ObjMap::iterator l_it = m_registered.find( p_key ); if ( l_it != m_registered.end() ) { l_return = l_it->second( p_params... ); } return l_return; } #else #endif   protected: ObjMap m_registered; };

---

Ce code fonctionne très bien sur un compilateur supportant les variadic templates, cependant j'aimerais savoir s'il y a possibilité de reproduire ce comportement avec un compilateur ne supportant pas les variadic templates, en gros, que puis-je mettre dans le #else?

J'ai essayé avec une bidouille de fonctions activées via les std::enable_if, en créant une structure template permettant de déduire le nombre de paramètres que prend la fonction de création, mais sans succès.

Quelqu'un a-t-il une idée?

Merci d'avance!

Bonjour,

Solution lourde mais très simple à comprendre : tu fais autant de version que tu veux gérer de paramètre :

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

template<class T1> ObjPtr Create( Key const & p_key, T1&& p1) { ObjPtr l_return; typename ObjMap::iterator l_it = m_registered.find( p_key ); if ( l_it != m_registered.end() ) { l_return = l_it->second(p1); } return l_return; }   template<class T1, class T2> ObjPtr Create( Key const & p_key, T1&& p1, T2&& p2) { ObjPtr l_return; typename ObjMap::iterator l_it = m_registered.find( p_key ); if ( l_it != m_registered.end() ) { l_return = l_it->second(p1,p2); } return l_return; }

---

Si tu peux utiliser boost, boost.PP devrait te permettre d'éviter d'écrire trop de code en utilisant le pré-compilateur pour faire les répétitions.

NB: Tu as oublié des forward dans ton code.

Le problème est là : je ne sais pas combien de paramêtres le Creator va nécessiter.
De plus à la déclaration d'une factory avec, par exemple, un Creator à 2 paramètres, le compilateur me gueule dessus à cause des autres fonctions qui essaient d'utiliser le Creator avec un nombre incorrect de paramètres.
Pour les forward ça n'a l'air de poser de problèmes ni à VC12 ni à GCC 4.7 (Debian Wheezy amd64), ni à GCC 4.8.1 (MinGW).
De plus je ne savais pas que l'on pouvait forwarder des paramètres variadiques comme ça...

tu as essayé avec les macro var_args ?

L'idée est de te fixer un nombre maximal de paramètre N, et d'écrire N+1 versions, c'est juste long à écrire, mais ça fonctionne parfaitement.

Par exemple ce foncteur avec des variadiques :

Code:

---

1 2 3 4 5 6 7 8 9

struct A { template<class... Arg> void operator()(Arg&&... arg) const { foo(std::forward<Arg>(arg)...); } };

---

Donne sans les variadiques :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

struct A { void operator()() const { foo(); } template<class T> void operator()(T&& arg) const { foo(std::forward<T>(t)); } template<class T1, class T2> void operator()(T1&& t1, T2&& t2) const { foo(std::forward<T1>(t1),std::forward<T2>(t2)); } template<class T1, class T2, class T3> void operator()(T1&& t1, T2&& t2, T3&& t3) const { foo(std::forward<T1>(t1),std::forward<T2>(t2),std::forward<T3>(t3)); } };

---

Là je gère au maximum 3 paramètres. Après boost.pp pour rendre ça plus simple à écrire, et dans ce cas le N est défini par une macro ce qui permet à un utilisateur de le changer si il a besoin de gérer un nombre maximal de paramètre plus important. (Code non testé, mais c'est l'idée à appliquer)

Pour ton problème de compilateur qui te stop à cause de fonction qui sont syntaxiquement invalides, c'est là qu'il faut utiliser le SFINAE / std::enable_if pour ne pas générer ces fonctions (ce n'est pas systématiquement nécessaire, on est dans une situation qui impliquent pas mal de template, ceux-ci ne sont générés que si ils sont utilisées, donc si ils doivent être syntaxiquement valide).

PS: Pour les forward le compilateur ne te dit rien car ton code est parfaitement valide, par contre il ne profite pas du perfect forwarding.

Salut,

As-tu déjà jeté un oeil au code que je propose dans cette discussion :question: Il pourrait peut être t'aider à trouver une solution ;)

Perso, j'ai simplement décidé d'utiliser des tuples pour maintenir la liste des paramètres requis par le constructeur. Mais le code de test indique tout cela... ;)

Effectivement ça pourrait être pas mal, sauf que, je n'ai pas envie de modifier les constructeurs (je sais, je suis une feignasse) des classes pour lesquelles je pourrais avoir besoin d'une factory.
Je n'en ai pas beaucoup, mais j'ai envide garder le code plus naturel que ce que ta factory impose.
En tout cas merci pour ton intérêt.

Bon, du coup je suis parti sur la première solution de Flop90:

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 48 49 50 51 52 53 54 55 56

ObjPtr Create( Key const & p_key ) { ObjPtr l_return; typename ObjMap::iterator l_it = m_registered.find( p_key );   if ( l_it != m_registered.end() ) { l_return = l_it->second(); }   return l_return; }   template< typename Param1 > ObjPtr Create( Key const & p_key, Param1 && p_p1 ) { ObjPtr l_return; typename ObjMap::iterator l_it = m_registered.find( p_key );   if ( l_it != m_registered.end() ) { l_return = l_it->second( std::forward( p_p1 ) ); }   return l_return; }   template< typename Param1, typename Param2 > ObjPtr Create( Key const & p_key, Param1 && p_p1, Param2 && p_p2 ) { ObjPtr l_return; typename ObjMap::iterator l_it = m_registered.find( p_key );   if ( l_it != m_registered.end() ) { l_return = l_it->second( std::forward( p_p1 ), std::forward( p_p2 ) ); }   return l_return; }   template< typename Param1, typename Param2, typename Param3 > ObjPtr Create( Key const & p_key, Param1 && p_p1, Param2 && p_p2, Param3 && p_p3 ) { ObjPtr l_return; typename ObjMap::iterator l_it = m_registered.find( p_key );   if ( l_it != m_registered.end() ) { l_return = l_it->second( std::forward< Param1 >( p_p1 ), std::forward< Param2 >( p_p2 ), std::forward< Param3 >( p_p3 ) ); }   return l_return; }   ...

---

C'est pas très joli mais ça marche bien.

Tu ne peux pas utiliser boost.PP ? Parce que si sur le fond c'est la même chose, c'est quand même plus flexible.

Je pourrais, mais je préfère limiter les dépendances externes.

C'est boost... il faut quasiment le considérer comme la deuxième moitié de la STL :D

Je sais, je connais les arguments pour, mais tant que je peux m'en passer, je m'en passe.

Boost.PP est header only :)

Rhaaa mais vous êtes chiants hein!
C'est pas beau les macros! Na!

dragonjoker59, techniquement, t'as pas besoin d'un compilateur pour faire un exécutable, tu peux aussi le faire avec un simple éditeur hexadécimal, bon courage. :aie:

Oui mais le langage m'apporte le fait de comprendre ce que j'écris et de pouvoir le modifier sans m'arracher les cheveux.
Là, la plus-value de Boost.PP est minime voire négligeable, je ne vois donc pas l'intérêt de l'ajouter, n'en déplaise aux inconditionnels de Boost.
C'est une libraire que j'aime bien et que j'utilise, mais pas à outrance.

Tu ne vois vraiment pas la plus value ? Eviter d'avoir à écrire N fois un morceau de code similaire et par extension d'avoir à le modifier N fois en cas d'évolution. Je ne trouve pas que c'est minime, devoir écrire plusieurs fois quelque chose de similaire c'est accroître le risque d'erreur.

Je ne le fais qu'à un endroit sur un millier de fichiers, donc oui, minime.