Discussion :

[oodini]

Hello,

Soient l'héritage suivant :

Code :

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

1
2
3
4
5
6
7
struct A
{
};
 
struct B : public A
{
};

Je voudrais avoir un truc du style :

Code :

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

1
2
3
4
5
6
7
8
9
struct Foo_A
{
    A member;
};
 
struct Foo_B : Foo_A
{
    B member;    // avec B cachant A
};

Fonctionnellement, ça a l'air de faire l'affaire, sauf que je Foo_A doit contenir des fonctions travaillant sur member (appel de fonctions virtuelles (ou CRTP)...).
Je pourrais mettre un pointeur, mais je devrais l'instancier en tant que A dans le constructeur de Foo_A, puis éventuellement le réinitialiser en tant que B dans Foo_B.
Ou alors que Foo_B passe un pointeur de B au constructeur de Foo_A pour un argument qui par défaut serait initialisé par une instanciation de A.
Ça ressemble un peu au patron "Pont", mais ce n'est guère satisfaisant, et peu élégant. En outre, je ferais du dynamique alors que j'ai une connaissance préalable du type de membre souhaité, ce qui devrait conduire à utiliser du statique.
Ce qui peut m'amener aux classes de politique, mais je me retrouve confronté au même problème : la politique de la classe fille devant écraser celle de la classe mère.

J'ai l'impression que la solution est simple, mais que je me suis posé trop de questions, et que ça m'a embrouillé...

[ternel]

En principe, tu as deux possibilités: la template et la variable.

Tu veux quelque chose qui change via l'héritage.

Je reprends avec des noms réels: A et B deviennent Police et PoliceConcrete, qui hérite de Police. J'imagine que tu pourrais avoir un C: AutrePoliceConcrete.

Avec les polices, tu n'as normalement pas d'héritage dans les utilisateurs.

Ca donnerait quelque chose commec a:mais la police devra survivre à l'instance de Bidule

Code :

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

1
2
3
4
5
6
class Bidule {
private:
    Police& police;
public:
    Bidule(Police& police): police(police) {}
}

Nous avons au moins un cours sur l'usage des polices, je l'avais lu il y a quelques mois, mais je ne sais plus duquel il s'agit exactement

En tenant à l'héritage dans les bidules, ça donnerait plutôt, a mon sens:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class Bidule {
protected:
    Police& police;
    Bidule(Police& police): police(police) {}
public:
    Bidule() : police(PoliceConcrete()) {}
};
 
class SuperBidule : public Bidule{
public:
    SuperBidule() : Bidule(AutrePoliceConcrete()) {}
};

Dans les deux cas, tu utilise le fait qu'une référence est polymorphique, mais statique.

[oodini]

Je reprends avec des noms réels: A et B deviennent Police et PoliceConcrete, qui hérite de Police. J'imagine que tu pourrais avoir un C: AutrePoliceConcrete.

POur info, dans mon exemple, A et B doivent toutes deux être instanciables, et donc concrètes.

Dans les deux cas, tu utilise le fait qu'une référence est polymorphique, mais statique.

Cette dernière phrase me laisse perplexe, mais ton histoire de référence m'ouvre effectivement une piste.

edit :

mais la police devra survivre à l'instance de bidule

En fait, après passage de mon code, ce n'est pas possible. Du moins, sémantiquement, ça n'a pas de sens.
Il faut donc passer par un pointeur...
Mais ça voudrait dire que je devrais dupliquer le constructeur de A : une version pour l'instanciation directe, qui initialise le pointeur, et une version protégée appelée par le classe fille, et qui prend une valeur pour le pointeur.

[ternel]

Les références sont polymorphiques, au sens que les fonctions virtuelles sont gérées, comme pour les pointeurs, et contrairement aux variables simples.

J'insiste encore, il faut faire très attention, dans le premier exemple, à la durée de vie de la police référencé. Le risque est la dangling reference

[ternel]

Il existe une autre manière de faire, à base de template, mais je ne me souviens pas de la forme canonique.
D'où mon renvoi aux cours. Regarde du coté des design patterns

[oodini]

Apparemment, j'arrive à m'en sortir avec un membre référence initialisé en déréférençant un pointeur construit à la volée dans l'initialisation.
En utilisant un pointeur intelligent, ça devrait faire l'affaire.

[Iradrille]

Hello,

Quelque chose comme ça n'irait pas ?

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
struct A { };
struct B : A { };
 
struct FooA {
   virtual A& member() {
      static A member_;
      return member_;
   }
};
 
struct FooB : FooA {
   virtual B& member() {
      static B member_;
      return member_;
   }
};

(A moins que B ne dérive pas de A ?)
En relisant B hérite bien de A.

Une version template est aussi possible.

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
struct A { };
struct B : A { };
struct C : A { };
 
struct FooA {
   virtual A& member() {
      static A member_;
      return member_;
   }
};
 
template <class T>
struct Foo : FooA {
   virtual T& member() {
      static T member_;
      return member_;
   }
};
 
struct FooB : Foo<B> { };
struct FooC : Foo<C> { };

[dragonjoker59]

@leternel : Pour SuperBidule, es-tu sûr que ça compile avec Gcc ? Parce que généralement il râle quand on initialise un paramètre de référence non constante avec un objet construit à la volée. (par contre il ne dit rien si la fonction attend une référence constante).

[ternel]

En effet, et il aura raison.
Il vaudrai mieux utiliser une statique dans la classe.

[the Hound]

Bonjour,

Je ne suis pas sûr d'avoir tout compris au problème ... Ceci :

Code :

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

1
2
3
4
5
6
7
8
template <typename T = A>
  class Foo_A {
    protected:
      T member;
  };
 
template <typename T = B>
  class Foo_B : public Foo_A<T> {};

... ne devrait-il pas faire l'affaire ? Ou alors j'ai vraiment rien compris

[ternel]

Le problème avec cette solution, c'est que la Police (A ou B) est intégrée au type, un Foo_B est un Foo_A<B>, non interchangeable avec un Foo_A<A>.

[oodini]

@leternel : Pour SuperBidule, es-tu sûr que ça compile avec Gcc ? Parce que généralement il râle quand on initialise un paramètre de référence non constante avec un objet construit à la volée. (par contre il ne dit rien si la fonction attend une référence constante).

Apparemment, il accepte de compiler ceci :

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
#include <iostream>
using namespace std;
 
struct A
{
	virtual void print()
	{
		cout << 2;
	}
};
 
struct B : public A
{
	virtual void print()
	{
		cout << 5;
	}
};
 
int main()
{
	A& bar = *(new A);
 
	ba.rprint();
 
	return 0;
}

[oodini]

Le problème avec cette solution, c'est que la Police (A ou B) est intégrée au type, un Foo_B est un Foo_A<B>, non interchangeable avec un Foo_A<A>.

J'ai surtout évité la solution template pour éviter de la duplication de code lors de l'instanciation statique.

[dragonjoker59]

@oodini : Pas étonnant qu'il compile le code que tu as mis, mais quel rapport acec ma remarque que tu cites ?

[white_tentacle]

Apparemment, il accepte de compiler ceci :

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
#include <iostream>
using namespace std;
 
struct A
{
	virtual void print()
	{
		cout << 2;
	}
};
 
struct B : public A
{
	virtual void print()
	{
		cout << 5;
	}
};
 
int main()
{
	A& bar = *(new A);
 
	ba.rprint();
 
	return 0;
}

Oui, mais tu leakes un pointeur.

Pourquoi tu n’envisages pas un unique_ptr plutôt qu’une référence ? Ça me semble plus adapté à ton problème.

[JolyLoic]

Fonctionnellement, ça a l'air de faire l'affaire, sauf que je Foo_A doit contenir des fonctions travaillant sur member (appel de fonctions virtuelles (ou CRTP)...).
[...]
En outre, je ferais du dynamique alors que j'ai une connaissance préalable du type de membre souhaité, ce qui devrait conduire à utiliser du statique.

Je trouve ces deux phrases contradictoires...

[oodini]

@oodini : Pas étonnant qu'il compile le code que tu as mis, mais quel rapport avec ma remarque que tu cites ?

Effectivement, pas de rapport.

[oodini]

Je trouve ces deux phrases contradictoires...

Tu fais référence à l'appel de fonctions virtuelles ?
Si oui, et que la piste envisagée est le statique, j'avais précisé la possibilité du CRTP.

[oodini]

Oui, mais tu leakes un pointeur.
Pourquoi tu n’envisages pas un unique_ptr plutôt qu’une référence ? Ça me semble plus adapté à ton problème.

Dans mon message de 16h, je précisais :

En utilisant un pointeur intelligent, ça devrait faire l'affaire.

[koala01]

Salut,

Avant de répondre à la question, je voudrais t'inciter à réfléchir posément au fait que tu aies (ou non) réellement besoin que foo_b hérite de foo_a.

Je ne dis pas que tu n'en as pas besoin, mais as tu réellement besoin de la possibilité de substituer foo_a et foo_b, ce qui devrait être -- conceptuellement parlant du moins -- la seule raison qui pourrait t'inciter à utiliser l'héritage public

Si tu n'a pas besoin de créer une collection de pointeurs sur foo_a qui puisse contenir des foo_b, l'héritage public classique n'est sans doute pas forcément la solution.

Peux être pourrais tu, à ce moment là, simplement utiliser une structure template sous une forme proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
template <typename T>
struct Foo{
    /*  on sait jamais, des fois que tu en aurais besoin :D */
    using value_type = T;
    value_type value;
};
 
int main(){
   Foo<A> fa; //fa.value --> struct A
   Foo<B> fb; //fb::value--> struct B

Si tu as besoin de la substituabilité et du polymorphisme, la meilleure solution est alors sans doute d'encapsuler la donnée et de rajouter une classe de base, sous une forme proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
/* Vu que A doit pouvoir être instanciée en tant que telle,
 * il est préférable de prévoir une classe de base pour la classe A ;-) 
 */
struct Interface{
    /* interface commune à A et à B, en fonctions
     * virtuelles (pures) si besoin
     */
};
struct A : public Interface{
};
struct B : public Interface{
};

et d'utiliser le retour co-variant sous une forme proche de

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
struct AbstractFoo{
    /* selon tes besoins, uniquement la version const ou
     * les deux versions (const et non const) de cette fonction ;-)
     */
    virtual Interface & value() = 0;
    virtual Interface const & value() const = 0;
};
struct Foo_A : public AbstractFoo{
   virtual A & value() {return a_;}
   virtual A const & value() const{return a_;}
   private:
      A a_;
};
struct Foo_B : public AbstractFoo{
 
   virtual B & value() {return b_;}
   virtual B const & value() const{return b_;}
   private:
      B b_;
}

De cette manière, si tu connais ton objet de type foo_XX comme étant du type de base, tu récupère d'office une référence sur un objet de type Interface, ce qui te permet de manipuler "n'importe quel objet dérivé de Interface" et , si tu en arrive à connaitre ton Foo_A comme un Foo_A (ou ton Foo_B comme étant un Foo_B), tu peux récupérer ton A ou ton B avec certitude, et l'utiliser en tant que tel

Les deux mots clé à retenir dans le cas présent sont encapsulation et le principe de ségrégation des interfaces