Discussion :

[Ulmo]

Bonjour,
Je constate que l'utilisation de template gêne l'utilisation de l'héritage et polymorphisme :

• D'une part, ClasseTemplate<B> ne dérive pas de ClasseTemplate<A> quand B dérive de A
• D'autre part, je ne peux pas utiliser de de conteneur pour manipuler à la fois des A et des B

Je peux contourner le second point avec une classe contenant un pointeur vers A (un genre de pimpl), qui doit gérer les copies.
Pour l'autre problème, je ne voit pas quoi faire.

Connaissez vous des solutions à tout cela ?

[JolyLoic]

Pour le premier point je suis généralement content que ce ne soit pas la cas. Pourrais-tu me donner un exemple où ça gênerait ?

Dans les cas où l'on aimerait une certaine interopérabilité (shared_ptr<A> a; shared_ptr<B> b; a=b, on résoud souvent ça en ajoutant un constructeur templatée qui transfère la compatibilité du type template sur la compatibilité du paramètre.

[dtrosset]

Bonjour,

Pour répondre à ta première question : "Pourquoi le dervrait-il ?"

Tu peux le faire simplement toi même, avec une spécialisation. Pourquoi vouloir l'imposer à tous ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class A {};
class B : public A {};
 
template <class T>
class ClassTemplate
{};
 
template <>
class ClassTemplate<B> : public ClassTemplate<A>
{};

Didier

[3DArchi]

Il est étrange de vouloir dériver T<B> de T<A> au prétexte que A dérive de B. Une classe template offre des services indépendants du type avec lequel elle est instanciée. Que signifie sémantiquement T<B> dérive de T<A>??? Ca sent le problème de conception...

Pour ton second point, tu dois pouvoir utiliser Boost.variant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
#include <iostream>
#include <vector>
#include <algorithm>
#include <boost/variant.hpp>
 
template<class T>
class Templ
{
public:
   void QuiSuisJe()const {T::QuiSuisJe();}
};
 
class A
{
public:
   static void QuiSuisJe(){std::cout<<"Je suis un A\n";}
};
 
class B
{
public:
   static void QuiSuisJe(){std::cout<<"Je suis un B\n";}
};
 
class visiteurQuiSuisJe : public boost::static_visitor<void>
{
public:
   template<class T>
    void operator()(T t_) const
    {
       t_.QuiSuisJe();
    }
 
};
 
struct QuiSuisJe
{
   void operator()(boost::variant<Templ<A>,Templ<B> > const &var_) const
   {
      boost::apply_visitor(visiteurQuiSuisJe(),var_);
   }
};
 
int main()
{
   std::vector<boost::variant<Templ<A>,Templ<B> > > vecteur_de_a_ou_b;
   vecteur_de_a_ou_b.push_back(Templ<A>());
   vecteur_de_a_ou_b.push_back(Templ<A>());
   vecteur_de_a_ou_b.push_back(Templ<B>());
   vecteur_de_a_ou_b.push_back(Templ<B>());
   vecteur_de_a_ou_b.push_back(Templ<A>());
   std::for_each(vecteur_de_a_ou_b.begin(),vecteur_de_a_ou_b.end(),QuiSuisJe());
   return 0;
}

[Kalith]

Ca peut paraitre utile quand on écrit des templates de smart pointers.
Mais comme l'a dit JolyLoic, on peut s'en passer avec un peu de bidouille :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
template<class T>
Pointer
{
public : 
 
    // ...
 
    template<class N>
    operator Pointer<N>()
    {
        return Pointer<N>(pValue_);
    }
 
private :
 
    T* pValue_
};

Mais il me semble qu'il y avais quelques limitations... je ne les ai plus en tête.

[white_tentacle]

Il est étrange de vouloir dériver T<B> de T<A> au prétexte que A dérive de B. Une classe template offre des services indépendants du type avec lequel elle est instanciée. Que signifie sémantiquement T<B> dérive de T<A>??? Ca sent le problème de conception...

En fait, c'est une erreur de conception assez répandue. L'idée qu'un array<B> dérive d'un array<A> si B dérive de A, qu'on retrouve en java, csharp, par exemple.

C'est une grosse erreur, et ça viole le LSP. Ce qui est dingue, c'est que des gens brillants la fassent encore.

Pour ton premier problème, tu peux passer par une interface (faire dériver ton template d'une interface, ainsi, T<B> et T<A> auront une interface commune, donc tu pourras avoir un conteneur de T<B> et T<A>). Ou alors, boost::any ou boost::variant.

[Ulmo]

Alors pour commencer, je suis tout à fait d'accord : en réfléchissant un peu, on se rend vite compte qu'il est plus sain que ces 2 point ne marchent pas.

J'accepte les accusations d'erreur de conception ! Il faut bien apprendre

C'est pour implémenter l'exploration du solitaire (défi en cours). Voici mon cheminement :
J'ai une classe EnsembleDeCases qui décrit les emplacements des cases du plateau, ou encore les emplacements des pions.
Et une classe Solitaire qui contient 2 EnsembleDeCases (pour les cases existantes et pour celles occupées) qui fera le travail (explorer les chemins possibles vers la solution).

Je me propose d'avoir différentes variantes pour EnsembleDeCases.
Solitaire ne peut pas dériver de EnsembleDeCases puisqu'il y en a 2 à l'intérieur. J'en fait donc un template.

En même temps, je souhaite définir une interface globale pour les EnsembleDeCases, que je fait donc dériver d'une classe abstraite.
Mais au final, ça ne sert à rien, car je ne peux pas manipuler de Solitaire<EnsembleDeCasesAbstrait> contenant soit Solitaire<EnsembleDeCases1> soit Solitaire<EnsembleDeCases2>.

Alors que j'aurais aimé écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Solitaire<EnsembleDeCasesAbstrait> *monSolitaire;
if (choixDImplementation1) {
    monSolitaire = new Solitaire<EnsembleDeCases1>;
} else if (choixDImplementation2) {
    monSolitaire = new Solitaire<EnsembleDeCases2>;
} else {
    monSolitaire = new Solitaire<EnsembleDeCases3>;
}
monSolitaire->init(unFichier);
monSolitaire->auBoulot();
if (monSolitaire->pasDErreur()) {
    monSolitaire->faitVoirCeQueTuAsFait(std::cout);
}
delete monSolitaire;

Résultat, le code init/auBoulot/... est à recopier pour chaque implémentation. C'est nul.

Bon, on s'en sort très bien, soit en utilisant une fonction template, soit en mettant des pointeurs dans Solitaire au lieu d'en faire un template.
Mais au final, je n'ai pas réussi à mélanger template et polymorphisme. Surprenant pour 2 fonctionnalités phare du langage.

Pour ton second point, tu dois pouvoir utiliser Boost.variant :

C'est lourd (boost nécessaire, une classe template supplémentaire) et je regrette que cela ne prenne pas en compte la relation entre A et B.
Mais ça répond à la question

C'est une grosse erreur, et ça viole le LSP.

LSP ?

Pour ton premier problème, tu peux passer par une interface (faire dériver ton template d'une interface, ainsi, T<B> et T<A> auront une interface commune, donc tu pourras avoir un conteneur de T<B> et T<A>).

Heu, si j'ai bien compris, tu dis que si A et B dérivent de Interface, je peux les mettre dans un std::list<Interface>.
C'est bien ce que j'avais en tête mais qui ne marche pas.
Que voulais tu dire, alors ?

[CedricMocquillon]

Citation:
Envoyé par white_tentacle Voir le message
C'est une grosse erreur, et ça viole le LSP.
LSP ?

http://en.wikipedia.org/wiki/Liskov_...tion_principle

[koala01]

Salut,

C'est pour implémenter l'exploration du solitaire (défi en cours).
<snip>

Je conçois que ce soit un bon moyen d'apprendre, mais, si c'est pour t'assurer d'une place au défi, ce n'est pas très honnête de poser la question sur le forum

Enfin...

Un conseil que l'on pourrait te donner est de veiller à la délégation des tâches.

Pour la plupart des jeux "de pions", l'idéal est de partir sur:

• Une classe "case" capable de dire si elle est libre ou non et si elle accepte
  de recevoir un pion (et/ou d'être survolée)
• une classe "pion" capable de donner les coordonnées de la case sur laquelle il se trouve
• une classe "joueur" pour "l'intelligence"
• une classe "partie" pour gérer les différents joueurs
• une classe "plateau" qui met les deux premières classes en relation et
  qui reçoit ses instructions (questionnement des pions et des cases et déplacement des pions) de la classe partie

Dans le cadre du solitaire, toutes les classes ne sont pas forcément nécessaires