Problème de l'héritage d'une fonction template

Bonjour,

je cherche un moyen de contourner l'impossibilité d'hériter d'un fonction membre template, quelqu'un a une idée?

Un peu de détails. Je voudrais faire ça:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

struct Father { template <typename T> virtual void bar( const T & param ) = 0; };   struct Son: public Father { template <typename T> void bar( const T & param ) { param.DoSomething(); } };

---

Evidemment ça ne compile pas parce qu'une fonction membre template ne peut pas être virtuelle (encore moins virtuelle pure donc).

Connaissez-vous des astuces pour contourner cette limitation?

Bonjour,

Pour imaginer une solution de contournement, il faudrait que tu dises ce que tu veux faire avec ces deux (ou plus classe) ? Dans quel contexte te sert cet héritage, pourquoi y-a-t'il un besoin de template dans ce contexte ?

En fait, c'est plus un problème théorique, général.
Je suis tombé sur ce problème concrètement dans un programme que sur lequel je travaille, et j'ai trouvé une solution simple (j'ai juste pas déclaré les fonctions dans la classe de base) et qui convient pour les besoins précis de cette appli. Mais je réfléchissais à une solution plus générique.
Déjà, je ne comprend pas le pourquoi de cette limitation. Qu'est-ce qui empêche le compilateur de mettre une fonction template dans la vtable?

Il faut bien voir qu'une fonction template n'a aucune réalité une fois la compilation passée, ce sont ces instanciations qui en ont une. D'où la problématique, je mets quoi comme instanciation dans la table ? La compilation se fait unité par unité puis ensuite l'ensemble est lié. Chaque unité pourrait déterminer ce qu'il a besoin de mettre dans la table, mais rien ne garantirait à l'éditeur de lien que le contenu de la table serait identique entre chaque unité.

Je ne comprends pas. Une fonction template n'a, qu'elle soit virtuelle ou non, de réalité qu'à l'instanciation. Je ne comprend donc pas ce que ça change qu'elle soit virtuelle :koi:

On va faire simple, disons que j'ai cette classe :

Code:

---

1 2 3 4 5 6

struct A { template<class> virtual void foo(){} };

---

Maintenant j'ai deux fichiers :

Code:

---

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

//B.cpp void bar(A& a) { a.foo<char>(); }   //C.cpp void goo() { A a; a.foo<int>(); bar(a); }

---

Après compilation, j'ai un truc (juste dans l'idée) du genre :

Code:

---

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

//B.obj foo_char(a) { a.table[0](a); }   bar(a) { foo_char(a); }   //C.obj foo_int(a) { a.table[0](a); }   goo() { a; a.table[0] = foo_int; foo_int(a); bar(a); }

---

L'éditeur de liens met tout ensemble, pas de problème, sauf qu'on se retrouve à appeler deux fois foo<int>à la place de foo<int> puis foo<char> dans goo(). Et le compilateur ne peut pas faire autrement, il n'y a qu'une instance dans chaque fichier, donc il considère une table a un seul élément.

Pour le problème initial, je soupçonne fort que T soit en réalité un variant, non ? Je doute que la fonction accepte n’importe quoi comme T.

Cela dit, je pense qu’une bonne solution pour ça, c’est le pattern NVI, avec un truc du genre :

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

class Father { protected: virtual void bar_(LightTWrapperBase& wrapper)=0; public: template<typename T> void bar(T const& param) { LightWrapper<T> p(param); bar_(p); } };   class Son : public Father { protected: void bar_(LightTWrapperBase& wrapper) override; };   // et class LightTWrapperBase { … // mettre ici les méthodes utiles en virtuelles pures };   template<typename T> class LightTWrapper { protected: T const& value; public: ... // override de la classe de base };

---

Note : ça coûte un appel virtuel en plus, et grossit probablement un peu l’exécutable.

Citation:

---

Envoyé par white_tentacle

Pour le problème initial, je soupçonne fort que T soit en réalité un variant, non ? Je doute que la fonction accepte n’importe quoi comme T.

---

Non non, dans mon code T est un type "classique", une structure. Et j'ai testé avec des types natifs, le résultat est le même.

Citation:

---

Envoyé par r0d

Non non, dans mon code T est un type "classique", une structure. Et j'ai testé avec des types natifs, le résultat est le même.

---

Ce que je voulais dire par là, c’est que tu as probablement des contraintes sur ton T, et donc, que tu peux extraire une interface (un concept) de ces contraintes.

Partant de là, tu peux utiliser un polymorphisme sur ton paramètre à la place de la généricité, soit directement sur tes types, soit au moyen d’un wrapper léger comme je l’ai fait dans mon exemple.

Ptin ça me soule j'y comprend rien aux templates c'est énervant. Pendant près de 10 ans, j'ai fais du c++ sans rien savoir sur les templates, et sans m'y intéresser (si si c'est possible), et j'en paie les frais maintenant... Vous avez pas un bon livre à me conseiller?

Modern c++ design.

Je pense aussi que pour bien faire, il te faudrait un bouquin de compilation précisant comment on implémente des templates façon c++, mais là, je ne sais pas quoi te conseiller (même pas sûr que ça existe sous forme de bouquin en fait).

"Modern c++ design" je le connais presque par cœur... En plus, il n'est plus vraiment à jour.
Comme tu dis, il me faudrait quelque chose de plus "bas niveau".

Dans ce cas, peut-être commencer par le Dragon Book (https://fr.wikipedia.org/wiki/Dragon_book).

Je ne sais plus s’il y a une partie consacrée à la généricité (je te confirme ça dès que je remets la main dessus). Dans tous les cas, c’est un must-read si tu veux des infos sur le fonctionnement d’un compilateur.

Une template, c'est précisément ce que dit son nom: un modèle de fonction, et surtout pas une fonction générique (à la java)
Il y aura plusieurs fonctions différentes créées à la compilation.

Ton problème est difficile parce qu'il est à l'intersection de plusieurs contraintes et optimisation.

Tu imagines bien que le compilateur ne peut pas générer à l'avance toutes les possibilités de la template (puisqu'elles sont infinies).
Du coup, il n'en génère aucune à l'avance.
Elles sont créées au besoin, là où c'est nécessaire.

Pour cette même raison, une template membre d'une classe n'est pas compilée avec la définition de la classe, mais plus tard, quand elle sera utilisé avec un type concret.

D'autre part, la virtualité repose sur le fait que les fonctions virtuelles existes à la fin de la définition de la classe.

C'est un problème de moment d'existence.

Juste une petite note: Ce n'est pas spécifiquement les fonctions templates qui ne peuvent pas être virtuelles, mais les fonctions "plus templates que leur classe".
Ce qui permet à une classe template d'avoir des fonctions virtuelles:

Code:

---

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

template<class T> struct A { virtual T* DoSomething(); //OK };   struct B : public A<int> { int* DoSomething(); };   template<class T> struct C : public A { T* DoSomething(); }

---

Citation:

---

Envoyé par white_tentacle

Pour le problème initial, je soupçonne fort que T soit en réalité un variant, non ? Je doute que la fonction accepte n’importe quoi comme T.

Cela dit, je pense qu’une bonne solution pour ça, c’est le pattern NVI, avec un truc du genre :

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

class Father { protected: virtual void bar_(LightTWrapperBase& wrapper)=0; public: template<typename T> void bar(T const& param) { LightWrapper<T> p(param); bar_(p); } };   class Son : public Father { protected: void bar_(LightTWrapperBase& wrapper) override; };   // et class LightTWrapperBase { … // mettre ici les méthodes utiles en virtuelles pures };   template<typename T> class LightTWrapper { protected: T const& value; public: ... // override de la classe de base };

---

Note : ça coûte un appel virtuel en plus, et grossit probablement un peu l’exécutable.

---

Soit j'ai encore rien compris, soit ça ne marche pas. Comment tu déclares les fonctions dans LightTWrapperBase? Je ne vois pas comment les déclarer sans qu'elles soient templates.

Citation:

---

Envoyé par r0d

Soit j'ai encore rien compris, soit ça ne marche pas. Comment tu déclares les fonctions dans LightTWrapperBase? Je ne vois pas comment les déclarer sans qu'elles soient templates.

---

Le T& est un membre de ta classe. Donc il ne figure plus dans les paramètres.

Je prends un exemple plus complet :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

struct LightWrapperBase { virtual int sum() = 0; };   template<typename T> struct LightWrapper : public LightWrapperBase { T const& ref; LightWrapper(T const& r_) : ref(r_) {} int sum() override { return ref.sum(); } };

---

Le seul soucis est si tu as besoin de renvoyer un T : là, ça ne marchera pas. Mais sinon, l’idée c’est :
- isoler l’interface (le concept) minimale que doit fournir T
- wrapper cette interface dans une classe de base
- faire une classe générique dérivant de cette interface fournissant les services

En fait, tu recrées une hiérarchie entre des objets qui n’en avaient pas, spécifique à ton besoin, pour utiliser un polymorphisme dynamique.

Ha ok je vois. Malheureusement, je suis dans le cas où j'ai besoin de renvoyer la valeur à d'autres fonctions templates :/ (Je n'ai besoin que de ça en fait).

La solution que j'ai implémenté hier fonctionne mal, car je ne peux plus bénéficier de la substitution du type de base.

Je me demande en fait si je ne serais pas en train de faire fausse route. Mon problème est le suivant:
J'ai un objet qui comporte quelques fonctions templates. Cet objet est une sorte de contrôleur de sérialisation: il prend des valeurs de types indéterminés (d'où les fonctions membres templates), effectue quelques vérifications et mise en forme, puis les envoie à la la lib de sérialization. Ça fonctionnait bien jusqu'à ce que mon chef (qui est tout sauf développeur) décide brutalement (et en contradiction avec le cahier des charges, mais ce sont les risques du métier) qu'il devrait être possible de sérializer de plusieurs façons, en fonction d'un argument de la command line (ce qui signifie que la décision se fait au runtime, pas à la compilation).
Je suis donc parti sur un DP template method: un objet SerializerBase avec les fonctions de serialization en virtuelles pures, et des héritages selon le type de serialization souhaitée. Et là bim, c'est le drame: je ne peux pas surcharger mes fonctions membre template. Et ta méthode ne fonctionne pas parce qu'il faut que je renvoie les valeurs reçues par ces fonctions au niveau N-1 (les libs de sérialization).

Ce qu'a dit Médinoc m'a donné une idée: peut-être qu'il faudrait plutôt que je "templatise" mon serializer plutôt que d'en faire une hiérarchie type "template method".

Comment marche ta lib de désérialisation ? Tu sais à l’avance quel type d’objet tu es en train de lire, ou tu reçois des objets arbitraires dont tu détermines le type au runtime (j’ai plutôt l’impression que tu es dans le premier cas).

Si c’est bien le premier cas, il n’y a que la désérialisation qui doit poser problème, et je pense qu’il y a une solution à base de double dispatch, quelque chose du genre :

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

struct DeserializerBase { ... template<typename T> T deserialize() { return this->deserialize_(LightWrapper(T)).as<T>); protected: virtual ResultBase& deserialize_(LightWrapperBase& wrap)=0; };   struct DeserializerJson : public DeserializerBase { void ResultBase& deserialize_(LightWrapperBase& wrap) { return wrap.deserialize(this); } template<typename T> T deserialize() { /* do the deserialization and return it */ ); };       template<typename T> struct LightWrapper : public LightWrapperBase { ResultBase& deserialize(DeserializerJson& deserializer) override { return ResultBase(deserializer.deserialize<T>(); } ResultBase& deserialize(DeserializerXml& deserializer) override { return ResultBase(deserializer.deserialize<T>(); } ... };

---

(fait en 10 min selon la méthode de la rache, mais vois-tu l’idée ?)