Discussion :

[YéTeeh]

Bonjour,

Le sujet complet est :
Un type paramètre d'une classe mère template doit-il matcher les besoins de la classe mère dans des méthodes qui sont redéfinies dans la classe fille ?

Ce n'est peut-être pas plus clair, mais des détails suivent.

J'ai un problème avec le code suivant :

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
#include <iostream>
 
struct S
{
  int a;
};
 
template <class T>
class A
{
public:
  // on appelle f() de la classe instanciée
  void g( const T& t ) { f(t); }
 
protected:
  virtual void f( const T& t ) { std::cout << t << std::endl; }
};
 
class B : public A<S>
{
protected:
  virtual void f( const S& t ) { std::cout << t.a << std::endl; }
};
 
int main()
{
  S s;
  s.a = 24;
 
  B b;
  b.g(s);
 
  return 0;
}

Le problème est que ça ne veut pas compiler :

test_template_virtual.cpp: In member function `void A<T>::f(const T&) [with T = S]':
test_template_virtual.cpp:12: instantiated from `void A<T>::g(const T&) [with T = S]'
test_template_virtual.cpp:29: instantiated from here
test_template_virtual.cpp:15: erreur: no match pour « operator<< » dans « std::cout << t »

Si je comprends bien, g++ voudrait que operator<<() soit défini pour S sous prétexte que ça serait utilisé dans A::f(). Sauf que moi, ce que je vois, c'est que A::f() n'est jamais appelée, et que la version B::f() est appelée à la place. Ou alors il y a quelque chose que je n'ai pas vu. Alors qui a les plus mauvais yeux, g++ ou moi ?

La version de g++ que j'utilise est la 3.4.4

Merci pour votre aide.

[Pragmateek]

Code :

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

template <class T>

Aucun rapport avec le probleme mais:

Code :

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

template <typename T>

est mieux.

[vdumont]

Javais une erreur qui ressemblait a cela et cetais du aux constructeurs de copie. Essaie den ajouter a tes classes pour voir.

[YéTeeh]

Javais une erreur qui ressemblait a cela et cetais du aux constructeurs de copie. Essaie den ajouter a tes classes pour voir.

désolé, ça ne change rien :

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
struct S
{
  S() {}
  S( const S& that ) {}
 
  int a;
};
 
template <typename T>
class A
{
public:
  A() {}
  A( const A<T>& that ) {}
 
  void g( const T& t ) { f(t); }
 
protected:
  virtual void f( const T& t ) { std::cout << t << std::endl; }
};
 
class B : public A<S>
{
public:
  B() {}
  B( const B& that ) {}
 
protected:
  virtual void f( const S& t ) { std::cout << t.a << std::endl; }
};

[YéTeeh]

Bon, j'ai une première idée, c'est horrible mais ça compile. Attention attention, accrochez-vous :

j'ai remplacé le corps de la fonction A::f() :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
template <typename T>
class A
{
public:
  A() {}
  A( const A<T>& that ) {}
 
  void g( const T& t ) { f(t); }
 
protected:
  virtual void f( const T& t ) { std::cout << *(int*)&t << std::endl; }
};

Terrible, non ?

En tout cas ça passe à la compilation et ça donne le résultat attendu à l'exécution.
Par contre, je ne peux plus instancier A avec un type comme unsigned int...

Si vous avez quoi que ce soit de plus respectable (le niveau est quand même très très bas), je suis preneur !

[Laurent Gomila]

Attention il ne faut pas confondre le comportement à la compilation et le comportement à l'execution.
En l'occurence, tu as un problème de compilation que tu tentes d'expliquer par un comportement à l'execution. Le fait est que le compilo, lorsqu'il tente de compiler A<S>, ne peut pas savoir que A::f ne sera jamais appelé. Donc il te signale bien l'erreur.

Mais je ne comprends pas ton design. Pourquoi ne pas faire une fonction f non virtuelle, et simplement définir un opérateur << pour S plutôt que de reléguer ce travail à B::f() ?

Que sont les classes S, A et B ?

[YéTeeh]

Alors dans le détail, ça devient un peu plus compliqué.

Je résous des problèmes de sac à dos en variables binaires. Je manipule des problèmes mono et bi-objectifs. En gros, étant donné une variable du problème, elle m'apporte deux profits si je la met dans mon sac : p1 et p2 (d'où le bi-objectif). Je dois quelque fois combiner ces profits p = a * p1 + b * p2 (on tombe dans du mono objectif).

L'idée du design est de ne pas avoir à réécrire plusieurs fois les algos de résolution selon que le problème à résoudre soit mono ou bi-objectif.

Au final, la classe A est un algorithme de branch & bound très bien pour le mono objectif, T est le type du problème à résoudre, et B est un branch & bound qui hérite de A et qui redéfini quelques méthodes pour que ça marche bien.

Si j'instancie A, alors T est mono-objectif, et le type du profit d'une variable est unsigned int. Si j'instancie B, alors T est bi-objectif, le type du profit est une structure avec deux champs : profit_1 et profit_2

Voilà pour le détail. Je peux redéfinir les opérateurs attendus dans A sur les profits bi-objectifs, mais ça demande beaucoup de temps et ça peux m'amener des erreurs vraiment difficiles à retrouver (j'ai essayé...). Par exemple, je pourrais involontairement appliquer un algo strictement mono objectif à un problème bi-objectif, et là, bonjour la galère.

En tout cas, merci pour votre aide.
Je suis toujours preneur pour de nouvelles idées.

[Luc Hermitte]

Est-il nécessaire d'y avoir un polymorphisme d'inclusion au milieu ?
Ne peux-tu te contenter simplement du polymorphisme paramétrique ?

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
struct S
{ int a; };
 
template <typename T> struct serializer {
    static std::ostream & w(std::ostream&os, T const& v) 
    { return os << v; }
};
 
template <> struct serializer<S> {
    static std::ostream & w(std::ostream&os, S const& v) 
    { return os << v.a; }
};
 
template <typename T> class A
{
public:
  // on appelle f() de la classe instanciée
  void g( const T& t ) { f(t); }
 
protected:
  void f( const T& t ) { serializer<T>::w(t); }
};
 
class B : public A<S>
{
protected:
    void whatever();
};
 
int main()
{
    S s;
    s.a = 24;
 
    B b;
    b.g(s);
 
    return 0;
}

[YéTeeh]

Ne peux-tu te contenter simplement du polymorphisme paramétrique ?

Je crois en effet que c'était la meilleure approche. Je n'aurais pas l'occasion de tester car je vais devoir utiliser un autre algo.

Merci à tous