Discussion :

[kremvax]

Bonjour,
Je souhaite savoir si vous connaissez une façon de résoudre l'ambiguïté qui survient lorsque j'ai une classe "petite-fille" (PF) qui dérive à la fois de F1 et F2, avec F1 et F2 dérivant à leur tour d'une classe mère M. Autrement dit, lorsque l'arbre de dérivation contient un cycle.
Il y a peut-être des subtilités du langage que je ne connais pas, est-il possible par exemple de faire un tel schéma en spécifiant que F1 doit primer sur F2 en cas d'ambiguïté?
Ou dois-je absolument revoir ma structure d'héritages?

[Médinoc]

De quelle ambiguïté parles-tu exactement dans le cas d'héritage en losange?

Aussi: renseigne-toi sur la notion de "classes de base virtuelle"

[kremvax]

Merci pour cette réponse, j'essaie de tester ça (ça à l'air de correspondre à mon problème).

Pour détailler, je déclare plusieurs classes :

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
 
class BaseObject
{
  // ...
};
 
class SynchObject : public BaseObject
{
  // ...
};
 
class GraphicObject : public BaseObject
{
  // ...
};
 
class MapObject : public GraphicObject, public SynchObject
{
  // ...
};

Ensuite, lorsque je dois caster un BaseObject* en MapObject*, j'obtiens une erreur sous VSexpress 2008 : "error C2594: 'cast de type'*: conversions ambiguës de 'BaseObject *' en 'MapObject *'"

[Médinoc]

En effet, et c'est bien parce que tu as deux BaseObject dans ta classe MapObject.

[kremvax]

Testé et approuvé, merci
Seul hic, je dois utiliser explicitement dynamic_cast désormais, sinon ça compile pas! Argh, 1 Mo de sources à corriger

[Médinoc]

D'un autre côté, on n'a jamais dit que l'héritage multiple était conseillé...

Java s'en passe très bien, se contentant des implémentations d'interface multiples. Tu peux aussi essayer le pattern Décorateur, mais c'est vrai qu'il n'est pas trop conseillé pour un langage sans GC...

[kremvax]

En fait je vais abandonner l'idée de l'héritage multiple dans ce cas-là, mais tout de même dans certains cas moins complexes je trouve ça bien pratique. C'est vrai que Java s'en passe très bien, c'est une façon légèrement différente de penser à son architecture mais lorsqu'on possède l'outil, autant le considérer

[3DArchi]

Disons que l'héritage multiple a son intérêt - par exemple justement pour réaliser plusieurs interfaces.
En revanche, l'architecture avec les trois classes que tu proposes me fait plus penser à un problème de conception. Quel est l'intérêt de BaseObject ? Quelle est la sémantique de ton héritage ? N'aurais-tu pas besoin d'une composition ?
Enfin, devoir faire un downcasting est aussi souvent indicateur d'un problème de conception. Soit tu ne manipules pas l'objet au bon endroit, soit ta classe de base n'a pas la bonne abstraction.
Le pattern décorateur peut être mis en place de manière sure en s'aidant des pointeurs intelligents.

[kremvax]

Salut 3DArchi,

Il faut savoir que j'évite d'utiliser la STL et les templates, par goût comme par nécessité (je programme entre autres pour des consoles de jeu, il me faut une portabilité maximale). Donc j'ai réécrit certaines choses, notamment une classe de listes chaînées qui utilise le type BaseObject. BaseObject contient aussi une fonction virtuelle "getType" implémentée par une partie de ses descendants, qui me permet de connaître le type de la classe fille ET d'une partie des classes parentes. Du coup, tu comprendras pourquoi je fais beaucoup de cast genre "MapObject * pMapObj = (MapObject*) pObj;".

C'est vrai que pour mon problème évoqué plus haut, le pattern décorateur pourrait convenir, mais bon j'ai fait autrement finalement...

[3DArchi]

Salut 3DArchi,

Il faut savoir que j'évite d'utiliser la STL et les templates, par goût comme par nécessité (je programme entre autres pour des consoles de jeu, il me faut une portabilité maximale).

Ayant travaillé sur de l'embarque, j'avoue ne pas comprendre cette réticence avec les templates. Autant, ton compilo peut ne pas avoir de STL ou une STL très peu performante, autant aujourd'hui, tu as forcément du template. Enfin, je vais peut être dire une énormité mais tant qu'à avoir du 'any', je me demande s'il ne vaut mieux pas carrément utiliser un void* plutôt que de tout faire dériver d'un BaseObject qui ne sert à rien...

[kremvax]

C'est en effet la STL qui ne passe pas sur certaines plateformes, pour ce qui est des templates c'est un choix personnel. L'avantage des templates ce serait qu'ils sont plus rapides à l'exécution que le polymorphisme, mais d'un autre côté on y perd en flexibilité. A l'utilisation il s'avère parfois pratique de pouvoir regrouper des objets hétérogènes dans une liste. Mon "BaseObject*" c'est une sorte de "void*" un peu amélioré avec deux ou trois fonctions. Un peu comme le "Object" de Java finalement. Après, c'est surtout une affaire de goût, je ne prêche rien du tout.

[3DArchi]

C'est en effet la STL qui ne passe pas sur certaines plateformes, pour ce qui est des templates c'est un choix personnel. L'avantage des templates ce serait qu'ils sont plus rapides à l'exécution que le polymorphisme, mais d'un autre côté on y perd en flexibilité. A l'utilisation il s'avère parfois pratique de pouvoir regrouper des objets hétérogènes dans une liste. Mon "BaseObject*" c'est une sorte de "void*" un peu amélioré avec deux ou trois fonctions. Un peu comme le "Object" de Java finalement. Après, c'est surtout une affaire de goût, je ne prêche rien du tout.

Je comprend ta démarche. A vrai dire, ce qui me gêne (d'un point de vue conception), c'est le BaseObject. J'ai l'impression qu'avec ce design tu risques de te créer plus de problème qu'autre chose. D'où l'idée de tant qu'à 'détyper' tes objets, autant passer par un void*.

[nicroman]

Moi... c'est pas tant le BaseObject qui me dérange que l'héritage multiple... Je comprends tout à fait comment ça marche, et pourquoi il est disponible en C++ (quoiqu'on puisse toujours s'en passer).

L'héritage est la relation entre deux classes la plus forte qui soit, et l'héritage en losange cache souvent une abstraction oubliée... D'une interface manquante... Bref... d'un simili decorator pattern (sans aller jusqu'au pattern complet dynamique).