Discussion :

[ep31]

Bon, je m'explique ;
suite à une implémentation de Garbage Collector enfin bref passons ; je viens de m'apercevoir que l'ordre de déclaration de l'implémentation d'interfaces dans une classe à une importance (chose que je n'ai jamais vue en C# et en Java).

Je m'explique, voilà mon exemple de code :

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
 
interface I1
{
public :
	virtual void SetI1 () = 0;
};
 
interface IInutil
{
public :
	virtual void SetIInutil () = 0;
};
 
class JeCollectionneCeQuiDerivedeI1
{
public :
	void AddElement (I1* param)
	{
		CString coincoin("coin coin");
	}
};
 
class MaClasseQuiHeriteDesDeuxInterface : public I1, public IInutil
{
public :
	MaClasseQuiHeriteDesDeuxInterface (JeCollectionneCeQuiDerivedeI1& jccqdi)
	{
		jccqdi.AddElement(this);
	};
	void SetI1 () {};
	void SetIInutil () {};
};

En voici l'utilisation :

Code :

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

1
2
3
 
			JeCollectionneCeQuiDerivedeI1 jccqddi;
			MaClasseQuiHeriteDesDeuxInterface* mcqhddi = new MaClasseQuiHeriteDesDeuxInterface(jccqddi);

Tout se passe impec quand je passe dans le constructeur de la variable mcqhddi, le this passé en paramètre de void AddElement (I1* param) a la même adresse que this c'est-à-dire adresse de this = adresse de param.

Par contre, si j'inverse l'ordre d'implémentation des interfaces dans ma classe :

Code :

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

1
2
3
4
 
...
class MaClasseQuiHeriteDesDeuxInterface : public IInutil, public I1
...

alors là dans le constructeur, je me retrouve avec un pointeur this qui est de 4 bits inférieur à la valeur de param. "Olé, c'est super !!!". Donc il doit y avoir un problème de vtbl, mon tableau de pointeur de fonctions virtuelles sur ma classe dépend de l'ordre de déclaration d'implémentation de mes interfaces dans cette classe. Ce qui me paraît plus que bizarre
Je viens de me repencher sur le bouquin "Mieux développer avec C++" et sur le bouquin de Stroujstrup (excusez pour l'orthographe), rien pas d'indice.
Donc si vous pouviez m'éclairer et me dire si vous aviez déjà eu ce cas-là.
Ou bien alors quelque-chose m'échappe et merci de bien vouloir m'éclairer ou alors ... tant pis

[JolyLoic]

Normal que tu n'aies pas vu ça en Java ou C#, ils ne supportent pas l'héritage multiple. Si tu as une classe C qui hérite de A et de B, Il faut bien stocker les données membre de A et de B quelque part, par exemple en commençant par celles de A, puis celles de B (je ne sais plus si l'ordre est spécifié, mais ça n'y change rien).

Donc, dans une fonction qui prend un A*, pas de problème, on peut lui passer directement l'adresse de ton C. Pour qu'une fonction qui prend un B* retrouve bien les données qui viennent de B, il faut appliquer un offset à ton C*. C'est cet offset qui doit provoquer le décalage que tu vois. Donc tout va bien.

Et la gestion de ces offsets est probablement une des raisons pour lesquelles certains implémenteurs de langages ont peur de l'héritage multiple.

[Médinoc]

C'est le cas aussi en java, où l'implémentation d'interfaces multiples évite les problèmes de données du à l'héritage multiple (notamment dans le cas d'héritage en losange).

Avec les interfaces, la seule donnée dupliquée et le pointeur de vtable, qui est constant et inaccessible à l'utilisateur.

Mais ça ne change rien au fait qu'une classe qui implémente deux interfaces possède deux pointeurs de vtable. Ils sont donc situés à deux endroits différents de la classe.
Pour régler le problème, la vtable de la seconde interface ne pointe pas directement sur les fonctions membres, mais sur des "thunk" qui font une soustraction sur le pointeur this avant d'appeler la fonction elle-même.

[ep31]

Normal que tu n'aies pas vu ça en Java ou C#, ils ne supportent pas l'héritage multiple.

Euh ... mon exemple montre bien un héritage d'INTRERFACE multiple et non un héritage de CLASSE multiple.

Code :

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

Pour régler le problème, la vtable de la seconde interface ne pointe pas directement sur les fonctions membres, mais sur des "thunk" qui font une soustraction sur le pointeur this avant d'appeler la fonction elle-même.

Tu veux dire par là que si j'ai par exemple une classe CC qui implémente d'abord I1, I2 puis I3 ; si une méthode d'une classe X prend en paramètre un pointeur de I3 et que je passe mon pointeur this de CC à la méthode de la classe X, le this se transformera en this.CC+(offset méthodes virtuelles de I1)+(offset méthodes virtuelles de I2) et donc pointeur au début de la vtbl de l'interface I3 ?

[ep31]

Euh ... mon exemple montre bien un héritage d'INTRERFACE multiple et non un héritage de CLASSE multiple.

Code :

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

Pour régler le problème, la vtable de la seconde interface ne pointe pas directement sur les fonctions membres, mais sur des "thunk" qui font une soustraction sur le pointeur this avant d'appeler la fonction elle-même.

Tu veux dire par là que si j'ai par exemple une classe CC qui implémente d'abord I1, I2 puis I3 ; si une méthode d'une classe X prend en paramètre un pointeur de I3 et que je passe mon pointeur this de CC à la méthode de la classe X, le this se transformera en this.CC+(offset méthodes virtuelles de I1)+(offset méthodes virtuelles de I2) et donc pointera au début de la vtbl de l'interface I3 ?

[Médinoc]

Pour être précis, ce ne sera pas exactement this qui sera passé, mais this + offset(pointeur vtable I3).
Typiquement, cet offset est égal à sizeof(classe mère) + sizeof(pointeur vtable I1) + sizeof(pointeur vtable I2).
C'est-à-dire, sur un système 32bits, sizeof(classe mère) + 8.

Et la classe aura donc trois ou quatre vtables :

• vtable pour les fonctions virtuelles de la classe mère.
• vtable pour I1
• vtable pour I2
• vtable pour I3

[ep31]

Ok merci pour tes éclaircissements
Je vais éviter désormais ralentir l'implémentation de Pattern et les choses trop complexes en C++. Repasser de JAVA à C++, c'est que du bonheur

[Médinoc]

Au fait: C'est une des raisons pourquoi il est fortement déconseillé d'utiliser des casts C-style en héritage multiple : Il faut être absolument certain que le cast sera un static_cast et non un reinterpret_cast, car un reinterpret_cast fausserait l'alignement.