Discussion :

[fafax]

Salut à tous,
Le code suivant (test.cpp) ne compile pas avec gcc (gnu).

Code :

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

1
2
3
4
5
6
7
8
9
struct A { int getValue()		{ return 33 ; } } ;
struct B { int getValue( int i )	{ return i * 2 ; } } ;
struct C : public A, B			{} ;
 
int main( int, char *[] )
	{
	C c ;
	c.getValue( 5 ) ;
	}

Voilà ce que donne la compilation :

Code :

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

1
2
3
4
5
6
7
8
test/test.cpp:11:4: error: request for member ‘getValue’ is ambiguous
  c.getValue( 5 ) ;
    ^
test/test.cpp:5:16: note: candidates are: int B::getValue(int)
 struct B { int getValue( int i ) { return i * 2 ; } } ;
                ^
test/test.cpp:4:16: note:                 int A::getValue()
 struct A { int getValue()  { return 33 ; } } ;

Ce n'est pas la première fois que je suis obligé de contourner le problème de la non-résolution d'un appel de méthode, par exemple en préfixant l'appel à la méthode non résolue par la classe propriétaire :

Code :

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

c.B::getValue( 5 ) ;

Mais ce n'est pas réellement satisfaisant ni très joli.
Sur internet je n'ai jamais trouvé de réponse, car les demandes sur ce problème portent en général sur des cas évidents.

Est-ce un bug du compilateur ou ai-je loupé quelque chose ?
Suis-je le seul à rencontrer ce problème ?
Merci

[Iradrille]

Hello,

Est-ce un bug du compilateur ou ai-je loupé quelque chose ?
Suis-je le seul à rencontrer ce problème ?
Merci

Les cas un peu bizarre avec de l'héritage multiples je connais pas trop, mais vu que MSVC donne la même erreur je dirai que ça ne vient pas du compilo et que t'es obligé de préciser la base pour lever l’ambiguïté.

Code :

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

1
2
3
4
1>main.cpp(13): error C2385: accès ambigu de 'getValue'
1>  main.cpp(13): note: peut être le 'getValue' en base 'A'
1>  main.cpp(13): note: ou peut être le 'getValue' en base 'B'
1>main.cpp(13): error C2660: 'A::getValue'*: la fonction ne prend pas 1 arguments

[Flob90]

Bonjour,

Le comportement est normal.

Quand le compilateur cherche le nom f, uniquement le nom (on oublie tout le reste, pas de notion de signature ou d'accessibilité), il commence par regarder dans la définition du type de *this. Si il trouve très bien, sinon il procède de manière récursive sur les types de bases directe, i.e. il fait comme si le type de *this était un des types de base direct. Il fusionne ensuite les résultats, pour qu'il y ait fusion il faut qu'un résultat inclue l'autre (pour faire simple), sinon il y a ambiguïté.

Dans ton exemple, il n'y a pas de getValue dans C donc il fait la recherche dans A et B, il trouve dans un cas A::getValue et dans l'autre B::getValue, puis vient la fusion, les deux résultats sont disjoints : ambiguité.

[JolyLoic]

Une façon simple de corriger ton code est de descendre les deux chaînes au niveau de C:

Code :

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

1
2
3
4
5
6
 
struct C : public A, B 
{
	using A::getValue;
	using B::getValue;
};

[fafax]

Quand le compilateur cherche le nom f, uniquement le nom (on oublie tout le reste, pas de notion de signature ou d'accessibilité), il commence par regarder dans la définition du type de *this.

Merci de cette explication.
Le polymorphisme n'est donc pas réalisé dans le contexte de l'héritage multiple.
C'est un point que j'apprends.

[fafax]

Une façon simple de corriger ton code est de descendre les deux chaînes au niveau de C:

Code :

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

1
2
3
4
5
6
 
struct C : public A, B 
{
	using A::getValue;
	using B::getValue;
};

Merci JolyLoic de cette solution, qui répond au problème en gardant l'élégance du polymorphisme

[koala01]

Salut,

Merci de cette explication.
Le polymorphisme n'est donc pas réalisé dans le contexte de l'héritage multiple.
C'est un point que j'apprends.

Si, le polymorphisme est totalement réalisé dans le cas de l'héritage multiple... Simplement il vient avec certaines restrictions qui sont tout à fait normales au demeurant : les fonctions des classes de bases (qu'elles soient virtuelles ou non) doivent être non ambigües.
Ainsi, si tu as un code 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
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
class A{
public:
    virtual void foo() const;
    /* ... */
}
void A::foo() const{
   std::cout<<"foo depuis un A\n";
}
class B{
public:
    virtual void bar() const;
};
void B::bar() const{
    std::cout<<"bar depuis un B \n";
}
class C : public A, public B{
public:
    void foo() const override;
    void bar() const override;
}
void C::foo() const{
    std::cout<<"foo depuis un C\n";
}
void C::bar() const{
    std::cout<<"bar depuis un C\n";
}
void truc(A const & a){
    a.foo();
}
void machin(B const & b){
    b.bar();
}
int main(){
    A a;
    B b;
    C c;
    truc(a); // OK : foo depuis un A
    truc(c); // OK : foo depuis un C
    machin(b); // OK : bar depuis un B
    machin(c); // OK : bar depuis un C
}

tu n'auras absolument aucun problème.

Du moins, tant que tu n'essayeras pas d'appeler une fonction qui existerait à la fois dans A et dans B