Discussion :

[boulouch]

Voici un cas tordu que j'ai rencontré récemment (sous Visual Studio 2008 v9.0) et qui me dérange un peu :

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
class A
{
public:
  virtual f();
};

class B:public A
{
protected: (ou private:)
  virtual f();
};

main()
{
A* inst = new B();
((B*)inst)->f();
inst->f();
}

- ((B*)inst)->f(); ne compile pas car f() de B est protected (ou private): logique.
- inst->f(); compile car f() de A est public : logique. A l'exécution, c'est en fait f() de B qui est appelé : toujours logique, polymorphisme oblige. Mon problème est que f() de B est protected (ou private) et ne devrait pas être appelable depuis une fonction extérieure à B.

1- Est-ce que modifier la visibilité d'une fonction virtuelle dans les classes dérivées est réellement légale ?
2- Est-ce que ce comportement est normal ?
3- Est-ce que je ne risque pas un comportement aléatoire en fonction du compilo et de l'environnement en général ?

[Aleph69]

Est-ce que des classes dérivent de B?
Sinon, alors le mot-clé virtual dans la classe B ne sert à rien me semble-t-il.
Après, aller modifier la visibilité d'une méthode d'un code dont on n'est pas l'auteur c'est toujours risqué. Il y a sûrement une bonne raison pour qu'elle ait été déclarée en protected (bien que dans ton exemple, je ne la vois pas non plus... ^^).

[bacelar]

Pour moi, c'est un refus d'héritage.
B ne devrait pas hérité publiquement de A.

[white_tentacle]

Si on se réfère à la norme :

If a virtual member function vf is declared in a class Base and in a class Derived, derived directly or indirectly from Base, a member function vf with the same name, parameter-type-list (8.3.5), cv-qualification, and ref-qualifier (or absence of same) as Base::vf is declared, then Derived::vf is also virtual (whether or not it is so declared) and it overrides 109 Base::vf.

La visibilité n'entre visiblement pas en ligne de compte.

Après, je ne vois pas l'intérêt qu'il y a à changer la visibilité dans la classe dérivée, mais je ne vois pas trop non plus ce qui l'empêche...

[gl]

Est-ce que des classes dérivent de B?
Sinon, alors le mot-clé virtual dans la classe B ne sert à rien me semble-t-il.

D'une manière générale, la présence de virtual dans la classe B n'est pas utile que l'on dérive ou non des classes depuis B. En effet f étant virtual dans A, elle le reste dans B que le mot clé soit présent ou non.

[Goten]

C'est quand même utile à mettre en tant que documentation. (même si oui il est implicite)

[gl]

C'est quand même utile à mettre en tant que documentation. (même si oui il est implicite)

Certes

[koala01]

Salut,

Le fait de redéfinir une fonction virtuelle en changeant sa visibilité est, surtout, une transgression grave du principe de subsitution de Liskov

En effet, si B hérite de A, c'est que tu estimes que tu peux envisager d'utiliser un pointeur ou une référence sur A partout où un B apparait, et de l'utiliser "comme s'il s'agissait d'un A".

Si B dispose d'une fonction membre protégée, c'est que tu estimes que cette fonction ne doit être appelable que depuis les fonctions membres des classes qui dérivent de B ou depuis les fonctions membres de B "himself".

De même, si B dispose d'une fonction membre privée, c'est que tu estimes que seules les fonctions membres de B doivent y avoir accès.

Or, tu ne peux garantir ces restrictions d'accès parce que... tu peux accéder à cette fonction grâce à... A qui ne dérive absolument pas de B, mais qui est sa classe mère

Si l'idée est de baliser la manière dont sera redéfinie une fonction virtuelle, il faut peut être te tourner vers le pattern NVI

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
#include <iostream>
using namespace std;
class A
{
 
    public:
        virtual ~A(){}
        void Someting()
        {
            (*this).doSometingExecute();
        }
    private:
        virtual void doSometing(){cout<<"Je suis un A"<<endl;}
};
class B : public A
{
    public:
        virtual ~B(){}
    private:
        virtual void doSometing(){cout<<"Je suis un B"<<endl;}
};
int main()
{
    A * ptr1 = new A;
    A * ptr2= new B;
    ptr1->doSometing(); // "Je suis un A"
    ptr2->doSometing(); // "Je suis un B"
    delete ptr1;
    delete ptr2;
    return 0;
}

[3DArchi]

Salut,

1- Est-ce que modifier la visibilité d'une fonction virtuelle dans les classes dérivées est réellement légale ?

C'est un choix du C++ de ne pas tenir compte de la visibilité lors de la résolution dynamique de l'appel. La visibilité n'est prise en compte qu'avec le type statique de l'expression mettant en jeu la fonction virtuelle. cf Fonctions virtuelles et visibilité

2- Est-ce que ce comportement est normal ?

Oui

3- Est-ce que je ne risque pas un comportement aléatoire en fonction du compilo et de l'environnement en général ?

Non.

[boulouch]

Merci à tous. Voilà un mystère éclairci.