Bonjour,

J'ai une fâcheuse tendance à confondre downcasting et upcasting. Qui désigne quoi ?

J'ai aussi un problème sur le même sujet:

J'ai une classe mère et des classes filles.
Je souhaiterai créer un tableau qui puisse contenir les instances de n'importe quelle classe dérivée de la classe mère (y compris la classe mère!).
J'ai alors essayé avec un tableau déclaré avec la classe mère, mais il est ensuite impossible de récupérer mes objets en tant qu' instances de classes filles, ce qui est plutôt logique après réflexion.
J'ai souvenir du pointeur void* , j'ai essayé sans succès. Je suppose que c'est du C ?

Comment remédier à ce petit problème ?

Merci !

J'imagine que tu essayais avec des cast de type C : "(Type)var"

Oui, c'est bien ça, merci !

Pour le downcasting et upcasting prend comme image un arbre généalogique où les parents sont les racines et les enfants des branches de plus en plus haute selon les générations...

les parents sont en bas et les enfants en haut

donc DOWNcasting c'est de déscendre d'un niveau : enfant -> Parent

UPcasting c'est le contraire : parent -> enfant.

Le downcasting est automatique comme transformer un int en char (en oubliant les warnings). Le upcasting n'est pas automatique car le compilateur ne veut pas prendre la resposabilité d'une erreur de segmentation ou d'incompatibilité c'est pourquoi il faut le spécifié nous même parce qu'on est des programmeurs : nous n'avons pas le droit à l'erreur

C'est le contraire.
Visualise une hiérarchie UML. Les parents sont en haut.

On upcaste (enfant -> parent) de façon implicite (c'est le mot).
Le downcasting (parent -> enfant) doit en revanche être explicité.

Généralement, chez le non-averti, le besoin de downcaster est le signe undubitable d'une erreur de conception.
Avoir une liste de parents pour downcaster pour manipuler des données de type enfant me parait typique de ce genre d'erreur de conception.

Pourquoi est-ce que tu mélanges divers types d'enfants dans ta liste ? Quel traitement voudrais-tu faire sur les enfants qui n'existe pas chez les parents ? Pourquoi ne pas avoir une liste d'enfants tout simplement ?

Citation : Imghs

le besoin de downcaster est le signe undubitable d'une erreur de conception

C'est probablement le cas...

Citation : Imghs

Pourquoi est-ce que tu mélanges divers types d'enfants dans ta liste ?

Mon tableau est utilisé pour contenir tous les objets du niveau d'un jeu 3D. Ma classe mère est un objet "générique" qui ne peut pas être affiché. De cette classe dérivent des objets affichables, des objets sonores, des objets physiques, et tout en bas du diagramme UML on a un objet représentant un personnage. Mais il y a certainement une meilleure manière de faire ?

Citation : Imghs

Quel traitement voudrais-tu faire sur les enfants qui n'existe pas chez les parents ?

Je voudrais effectuer des opérations qui sont particulières à chaque type d'objet (par exemple pour un objet physique, définir la masse).

Citation : Imghs

Pourquoi ne pas avoir une liste d'enfants tout simplement ?

Mon diagramme n'est pas linéaire (il est en forme d'arbre), il y a plusieurs enfants au même "niveau" du diagramme.

Il n'y a pas de sens d'avoir des objets d'une scène 3D qui ne soient pas affichables.

Si tu préfères, tu définis une fonction virtuelle render() qui se traduira par un affichage ou un son.

Citation : wetneb

Citation : lmghs

Quel traitement voudrais-tu faire sur les enfants qui n'existe pas chez les parents ?

Je voudrais effectuer des opérations qui sont particulières à chaque type d'objet (par exemple pour un objet physique, définir la masse).

Ce n'est pas une opération. C'est un attribut sans impact ni intérêt pour une liste d'objets 3D.

Si tu regroupes tes objets dans une liste, c'est pour appliquer des opérations sur ces objets.
Si une opération n'est pas applicable sur tous les objets de la liste (au moment où la seule chose que tu vois est cette liste), c'est que ces objets n'ont pas à être mélangés ensemble dans une même liste.

Je me suis mal exprimé (j'ai édité). Il ne s'agit pas de faire une simple scène 3D, mais un environnement interactif. Un objet qui ne s'affiche pas pourrait servir de "déclencheur" d'évènement quand tel ou tel objet entre en collision avec cet objet.
La physique aurait alors son utilité, non ?

Selon moi, il vaut mieux séparer le moteur physique du moteur 3D. c.f. par exemple le tuto sur les jeux 3D de developpez.com

J'ai pas bien compris ce que c'ets le downcasting et l'upcasting, quelqu'un pourrai-t-il me l'expliquer?

Si tu as une classe B qui hérite d'une classe A. Il est possible de faire passer une instance de B pour une instance de A. C'est de l'upcasting. Dans l'autre sens c'est du downcasting.

Ah ok, est donc c'est le downcasting qui est "sale"? Car moi j'utilise l'upcasting, et ça m'arrangerai pas de voir que c'ets pas super top

Oui le downcasting cay le mal si je puis dire ;-)

Enfin disons que mal utilisé c'est sale.