Discussion :

[k1000]

Bonjour,

Dans le cadre du d�veloppement d'une biblioth�que, je suis tomb� sur un os assez costaud. Voici une description du probl�me, si quelqu'un a une id�e :

J'ai une classe A qui contient un membre v.
J'ai une classe B qui h�rite de A � un certain niveau (telles que pour b de type B, b.A::v est accessible publiquement).

Je veux �crire une classe template C<T, n> telle que si B h�rite de C<B, n>, alors la construction d'un objet b de type B assigne n � b.A::v.

Pour l'instant, j'ai trouv� la solution suivante :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
struct A { int v; };
template<typename D, int n>
struct C {
  C() {
    D* dhis = static_cast<D*>(this);
    A* ahis = static_cast<A*>(this);
    ahis->v = n;
  }
};

Ce code fonctionne bien dans la plupart des cas, mais il y a un hic dans le cas d'h�ritage virtuel :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
// le code précédent
struct X: A { virtual ~X() {} };
struct B : virtual X, C<B, 13> {};

En effet, la construction d'une instance de B segfaute.
Quelqu'un aurait-il une id�e sur un moyen de g�n�raliser ce dispositif ?

[oodini]

�a ne te tente pas, l'utilisation des constructeurs ?

[k1000]

La proc�dure qui assigne b.A::v est bien situ�e dans le constructeur de C.

Le but est de faire en sorte que C<> agisse de mani�re parfaitement transparente pour B, donc notamment pas de code dans le constructeur de B.

[oodini]

Je dois avouer que je suis un peu paum� dans ton graphe d'h�ritage avec A, B, C et X.

[Iradrille]

Le but est de faire en sorte que C<> agisse de mani�re parfaitement transparente pour B, donc notamment pas de code dans le constructeur de B.

Au final le but serait d'avoir

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
struct B : /* virtual */ A, /* private */ C<B, 13> {
 
};

Au lieu de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
struct B : /* virtual */ A {
	B() : A(13) { }
};

?

Ca me semble une utilisation abusive des templates, �a n'apporte � priori rien, mais augmentera certainement le temps de compilation et la complexit� du code.

[oodini]

J'ai du mal � comprendre ce que tu cherches � obtenir, et donc � t'orienter vers une solution.

Aurais-tu un cas d'usage qui justifie le besoin que tu exprimes (et que j'ai du mal � saisir) ?

[k1000]

Au final le but serait d'avoir

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
struct B : /* virtual */ A, /* private */ C<B, 13> {
 
};

Au lieu de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
struct B : /* virtual */ A {
	B() : A(13) { }
};

?

Oui, c'est bien �a.

Ca me semble une utilisation abusive des templates, �a n'apporte � priori rien, mais augmentera certainement le temps de compilation et la complexit� du code.

Je suis d'accord que c'est un capillotract� comme utilisation (c'est d'ailleurs pour �a que probl�me).

En fait ce pattern me sert dans une biblioth�que :
- je fournis C<>, qui est en r�alit� une assez grosse classe
- A et B sont �crites par l'utilisateur (donc je n'ai pas la possibilit� d'ajouter un argument au constructeur de A)

Je souhaite donc �tre le moins intrusif possible.

Aurais-tu un cas d'usage qui justifie le besoin que tu exprimes (et que j'ai du mal � saisir) ?

Si tu veux la petite histoire : le membre A::v (d'un type bien plus complexe que int), sert en fait d'identifiant de la classe. Cet identifiant est ensuite utilis� pour faire une sorte de switch sur le type dynamique de l'objet cr�� (de mani�re plus efficace qu'une cha�ne de dynamic_cast, et _sans_ avoir besoin de rajouter des fonctions virtuelles).
Je me rapatrierai sur une autre impl�mentation si je peux d�montrer que c'est impossible. Mais pour l'instant, c'est le design le plus performant que j'aie.

[oodini]

OK.

� pr�sent, r�explique-nous cette histoire de membre v, � la lumi�re de ton dernier message.

[oodini]

Si tu veux la petite histoire : le membre A::v (d'un type bien plus complexe que int), sert en fait d'identifiant de la classe. Cet identifiant est ensuite utilis� pour faire une sorte de switch sur le type dynamique de l'objet cr�� (de mani�re plus efficace qu'une cha�ne de dynamic_cast, et _sans_ avoir besoin de rajouter des fonctions virtuelles).
Je me rapatrierai sur une autre impl�mentation si je peux d�montrer que c'est impossible. Mais pour l'instant, c'est le design le plus performant que j'aie.

Hmmm.... L'utilisation d'un switch est rarement justifi�e.
Je comprend ton envie/besoin d'�viter la virtualit� (bien que tu veuilles utiliser un h�ritage virtuel...), mais as-tu �tudi� le polymorphisme statique (CRTP) ?
Ou les classes de trait ?