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

[white_tentacle]

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 ?

C'est exactement ce que j'ai dit, et ça marche (dans un std::list<Interface*>).

Est-ce que tu peux détailler un peu plus ce qui ne marche pas ?

As-tu bien écrit ? :

Code :

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

1
2
3
4
5
6
7
8
9
class Interface {
...
};
 
template<typename T>
class A : public Interface
{
...
};

[Ulmo]

C'est exactement ce que j'ai dit, et ça marche (dans un std::list<Interface*>).

Est-ce que tu peux détailler un peu plus ce qui ne marche pas ?

C'est parce que je ne pensais qu'à un std::list<Interface &>, pour ne pas avoir à gérer la mémoire.
Pas très malin sur ce coup :-/

[Davidbrcz]

Les références sont des allias sur des objets existants. Elle n'ont pas d'adresse propre, impossible de les mettre dans un conteneur alors.

[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

[Ulmo]

Je suis désolé que cela prête ainsi à confusion, il aurait été plus clair que j'attende encore une semaine avant de poser mes questions.

Mon code quasiment est prêt; j'y fait régulièrement quelques retouches mais je n'en changerai plus l'architecture.

J'ai croisé quelques problèmes d'organisation au cours du développement, que j'ai contournés au mieux avec mes idées du moment.
Je souhaite donc avoir des avis de gens différents, voir plus compétents.
Comme au final, ce sont bien des questions d'architecture et pas des questions spécifiques au solitaire, je pose la question de façon abstraite. Ce n'est pas pour cacher ma demande d'aide.

[Alp]

Pour par exemple stocker indifféremment des MaClasseTemplate<A> et des MaClasseTemplate<B>, tu fais dériver la classe template d'une classe de base.

Après, il faut voir si c'est vraiment une bonne solution. Je pense que je commence à radoter, mais l'héritage ce n'est pas un outil à tout faire du C++. Il est sur-utilisé.

[3DArchi]

Je pense que je commence à radoter, mais l'héritage ce n'est pas un outil à tout faire du C++. Il est sur-utilisé.

D'où, je pense que ma proposition avec boost::variant est plus 'élégante' (question de gout bien sûr) et c'est pas si lourd que ça

[babar63]

Pour par exemple stocker indifféremment des MaClasseTemplate<A> et des MaClasseTemplate<B>, tu fais dériver la classe template d'une classe de base.

Après, il faut voir si c'est vraiment une bonne solution. Je pense que je commence à radoter, mais l'héritage ce n'est pas un outil à tout faire du C++. Il est sur-utilisé.

Surtout que dans ce cas et niveau conceptuel, il n'y a absolument aucun sens à vouloir utiliser l'héritage si c'est juste pour pouvoir les stocker dans le même container... c'est comme ça que peuvent commencer les problèmes de conception qui en entrainent par la suite des bien plus difficile à résoudre à force de "rafistolage maladroit". La solution de 3DArchi est en effet bien plus logique (à mon sens).

[Ulmo]

Surtout que dans ce cas et niveau conceptuel, il n'y a absolument aucun sens à vouloir utiliser l'héritage si c'est juste pour pouvoir les stocker dans le même container... c'est comme ça que peuvent commencer les problèmes de conception qui en entrainent par la suite des bien plus difficile à résoudre à force de "rafistolage maladroit". La solution de 3DArchi est en effet bien plus logique (à mon sens).

Je prend note, "ne pas sur-estimer l'héritage".
Facile à retenir, c'est comme avec Papi.

(Dans mon cas, il y aurait eu une interface commune. Je pense donc que l'héritage se défendait.)