Discussion :

[vandamme]

Voila, j'ai une classe de base B et une classe derivee D qui herite de B.
B et C implementent une methode virtuelle get() telle que :

Code :

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

1
2
3
4
5
6
7
8
9
class B
{
    virtual Widget1 get() { ... }
};
 
class D : public B
{
    virtual Widget2 get() { ... }
};

Etant donne qu'il n'y a aucune relation d'heritage entre les type de retour Widget1 et Widget2, il me dit qu'il y a incompatibilite dans les types de retour. Si j'enleve le virtual ca marche par contre mais n'y a t - il pas masquage alors dans ce cas ?

[Laurent Gomila]

Si j'enleve le virtual ca marche par contre mais n'y a t - il pas masquage alors dans ce cas ?

Si.

[Bruno Gillet]

En vait, virtual te permet de choisir au runtime quelle fonction sera exécutée.

Je problème, c'est que le C++ ne peux pas décider quelle fonction prendre sur base du seul changement du type de retour (tu ne peux pas avoir 2 fonctions avec les prototypes qui changent uniquement sur la base du type de retour). Et c'est ce que tu fait avec ton héritage.

[vandamme]

Donc, dans mon cas, il ne vaut mieux pas utiliser l'heritage alors ?

[koala01]

Salut,

En vait, virtual te permet de choisir au runtime quelle fonction sera exécutée.

Je problème, c'est que le C++ ne peux pas décider quelle fonction prendre sur base du seul changement du type de retour (tu ne peux pas avoir 2 fonctions avec les prototypes qui changent uniquement sur la base du type de retour). Et c'est ce que tu fait avec ton héritage.

Ce n'est pas tout à fait vrai... il existe un concept qui s'appelle le "retour co-variant" qui permet, justement, de renvoyer des types différents.

La limite étant qu'il faut renvoyer soit un pointeur soit une référence et qu'il y ait une relation d'héritage qui unisse les différents types (on crée alors le prototype dans l'interface avec la classe de base et ceux dans les classes d'implémentaiton avec les types concrèts )

Un code du genre 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
 
class A
{
    /*...*/
};
class B:public A
{
    /*...*/
};
class C:public A
{
    /*...*/
};
class Base
{
    public:
        /*...*/
        virtual A& GetVal()=0;
};
class D1:public Base
{
    public:
        /*...*/
        virtual B& GetVal(){return b;}
    private:
        B b;
};
class D2:public Base
{
    public:
        /*...*/
        virtual C& GetVal(){return c;}
    private:
        C c;
};

étant tout à fait valide...

@ Bruno Gillet: Peut être te baser sur les explications ci-dessus pour créer une interface qui te permettrait de retomber sur une classe mere commune à tes deux widget

[Bruno Gillet]

Donc, dans mon cas, il ne vaut mieux pas utiliser l'heritage alors ?

A quoi celà va-t-il servir ?
Le but de ce que tu fait en OO est de pouvoir écrire

Code :

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

1
2
 
x = obj->get()

et de ne pas devoir tenir compte de quelle fonction sera appelée.

Comment va-tu définir x dans le cas précédent ? Widget1 ? Widget2 ?

[vandamme]

Oui, tu as raison. C'est clair. Surtout qu'il n'y a aucun redesign possible pour faire une relation d'heritage entre Widget1 et Widget2

[Bruno Gillet]

Salut,
Ce n'est pas tout à fait vrai... il existe un concept qui s'appelle le "retour co-variant" qui permet, justement, de renvoyer des types différents.

Entièrement d'accord avec toi

[koala01]

Ceci dit, il n'y a aucune limite quant au niveau de l'héritage des types de retours...

Si widget1 hérite d'une classe qui hérite d'une classe qui hérite (...) d'une classe object et que widget2 est aussi dans le cas, ca marche tout aussi bien

Bien sur, j'interprète peut peut être à tord le fait que widget1 et widget2 soient des objets de bibliothèque graphiques... mais, sinon, tu trouvera sans "grosse" difficulté une classe "ancètre" commune