Discussion :

[fezvez]

Bonjour,

J'ai un splendide bout de code qui ne compile pas, et je souhaite vraiment vous en faire part :

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
class A
{
public:
  virtual void f(int i){}
};
 
class B : public A
{
public:
  void f(int i, int j){}
};
 
int main(int argc, char *argv[]){
  B instance;
  instance.f(42);
}

Il y a une erreur à la ligne instance.f(42) qui dit :

error: no matching function for call to ‘B::f(int)’

Je me dis qu'il est naturel que lorsque on appelle B::f(int), le compilo aille chercher la déclaration de la classe A (ou procède récursivement jusqu'à trouver une classe déclarant le bon prototype)

Sauf que ce n'est pas le cas. Et je voudrais savoir quelles sont les raisons qui ont poussé à cela

Car, il ne me semble pas que ce soit affreux du point de vue design : on a une fonction qui renvoie des informations. Plus on se spécialise, plus on peut renvoyer des infos pertinentes, et on dispose de choix plus variés pour poser nos questions (i.e : on a plus de prototypes à notre disposition)

Je ne suis pas arrivé à trouver ma réponse sur Google, donc je m'adresse à vous!

P.S : Je ne cherche pas un workaround, honnêtement, il y a 100 façons de procéder autrement. Je veux juste savoir pourquoi les hautes instances du C++ ont décidé de limiter la portée des appels

Edit : Je persiste, je ne comprend pas pourquoi je dois faire appel à l'opérateur de résolution de portée alors qu'il n'y a pas d'ambiguïtés sur le prototype de la fonction...
Ca veut dire que la ligne suivante fonctionne :

Code :

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

instance.A::f(42);

[zul]

Parce que le comportement polymorphe, ça ne marche que pour les pointeurs et les références ?

[3DArchi]

Salut,
Les fonctions virtuelles en C++ : Masquage d'une fonction virtuelle par une fonction non virtuelle.
using est encore la meilleur solution pour ramener la fonction masquée.
En fait, c'est vrai des fonctions même non virtuelles :

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 base
{
    void fonction();
};
 
struct derivee : public base
{
    void fonction(int);
};
 
int main()
{
    derivee d;
    d.fonction(); // error: no matching function for call to 'derivee::fonction()'
    return 0;
}

Disons que c'est comme pour une variable : si une variable est définie dans la même portée (scope) qu'une autre variable de même nom, tu as une erreur (pour une fonction tu as une surcharge plutôt qu'une erreur). Alors que si les 2 variables ont des portées (scope) différentes, c'est un masquage qui intervient :

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
struct base
{
    int variable;
    double variable; // erreur variable déjà définie
 
   void fonction();
   void fonction(double); // surcharge
};
 
struct derivee : public base
{
    double variable; // OK. base::variable est masquée par derivee::variable
 
   void fonction(int);//masquage des fonctions de base
};

Un nom masque celui d'un scope plus haut qu'il s'agisse d'une fonction ou d'une variable :

Code :

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

1
2
3
4
5
6
7
8
9
struct base
{
    int fonction;
};
 
struct derivee : public base
{
    void fonction(); // masque base::fonction
};

La classe dérivée et la classe de base correspondent à 2 scope différents.

Avec tout ça on voit que c'est quand même plus cohérent d'avoir ce comportement.

[fezvez]

Et bien, que dire sinon merci

Le parallèle fonctions/attributs aide à comprendre. C'est amusant, je découvre actuellement le Lua, et je pense que je n'aurais pas eu la même réflexion dans ce langage! (vu que pour le coup, attributs et fonctions, c'est presque la même chose)