Downcasting

Bonjour!

Je suis toujours en train de préparer mon exam de C++.
Dans une question ou je dois décrire l'upcasting et downcasting, la sous-question suivante est posée :
"Pourquoi le downcasting est-il souvent utilisé dans le cas de l'utilisation d'une librairie C++?"
Quelqu'un pourrait-il m'éclairer svp?
Merci d'avance!

En ce qui me concerne je l'utilise rarement. L'exemple que j'ai en tête c'est dans les toolkit graphiques avec un tree control, quand tu dois filer un TreeItem* (par exemple), et que toi tu veux les différencier. L'exemple type c'est une arborescence de répertoires, tu veux distinguer les répertoires des fichiers. Toi tu as défini TreeItemFile et TreeItemDir, mais tu n'as pas le choix car le controle n'accepte que des TreeItem.
Alors tu lui files des TreeItemFile et TreeItemDir qu'il manipule comme des TreeItem, et plus tard tu tests / downcast chaque TreeItem pour savoir si c'est un File ou un Dir via des dynamic_cast ou autre.
Pour généraliser, je dirais que c'est quand cette "librairie" (on dit bibliothèque en français) impose une interface qui ne te satisfait pas et que tu souhaites dériver. Difficile à expliquer...
A mois que la question sous-entende une horreur genre caster des void*...

ahhh ! le castage des void* ! les souvenirs :)
Pour ton exemple d'abre, c'est plutot un exemple de polymorphisme non ?

upcasting et downcasting c'est l'action de transtyper respectivement vers une classe mere ou vers une classe fille.

On downcaste souvent si on a une interface. Si tu as des classes rectangle, triangle, cercle qui derivent de forme et que tu veux les stocker dans un vector, tu fais un vector de pointeur vers le type forme puis tu pourras lui associer ce que tu veux comme sous-classe et downcaster (avec static_cast ou dynamic_cast) pour l'utiliser convenablement.

Code:

---

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

#include <iostream> using namespace std;   class forme { public: forme() {} virtual void draw () {} virtual ~draw () {} };   class rectangle : public forme { public: rectangle () : forme() {} void draw () { cout << "bla" << endl; } };   class triangle : public forme { public: triangle () : forme() {} void draw () { cout << "beuh" << endl; } };   int main () { forme* p = new rectangle; rectangle* pt = static_cast<rectangle*> (p); pt->draw(); delete p; p = new triangle; triangle *pt1 = static_cast<triangle*> (p); pt->draw(); delete p; system("pause"); return 0; }

---

enfin, un truc du genre.

typiquement tu retrouve en situation de downcaster quand :
-tu utilises un stockage polymorphique, cas du Tree graphique evoqué plus haut, quand tu prends un element tu obtiens forcement un element du type de base... C'est souvent le cas quand tu dois deriver un type de base fourni par une lib qui fourni elle-meme un moyen de stockage des instances...

Autre situation : lorsque tu écris des plugins pour une application. L'application ne connait que la classe de base, mais toi dans ta DLL tu en manipules une dérivée. Donc typiquement lorsque ta DLL va te transmettre un pointeur sur classe de base toi tu vas downcaster pour avoir un pointeur sur ta classe dérivée.

Exemple : un moteur 3D manipule des Texture*. Toi tu écris un système de rendu basé sur OpenGL -> tu vas caster les Texture* reçues en TextureOpenGL*. Et dans le module DirectX tu vas les caster en TextureDirectX* par exemple.

Ce qui me gêne dans sa question c'est le "souvent". J'ai tendance à considérer le downcasting comme un mauvais design, surtout en C++. En général avec les fonctions virtuelles tu t'en sors bien.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Ce qui me gêne dans sa question c'est le "souvent". J'ai tendance à considérer le downcasting comme un mauvais design, surtout en C++. En général avec les fonctions virtuelles tu t'en sors bien.

---

+1.
Ne pas oublier que ce genre de situation reste rare et que bien souvent le downcasting peut être avantageusement évité.

Citation:

---

Envoyé par Mookie

"Pourquoi le downcasting est-il souvent utilisé dans le cas de l'utilisation d'une librairie C++?"

---

Parce qu'il existe en C++ des bibliothèques mal conçues ?

A la limite, la question aurait été la même en Java en non en C++, j'aurais pu faire une réponse plus pertinente ("Parce que le manque de template rend ça obligatoire"), même si ça évolue un peu.

Mais vraiment, en C++, je vois pas...

Si si, y'a le void*....http://arb.developpez.com/smileys/fear.gif

Merci à tous pour vos réponses.
Je viens de trouver ceci dans mon syllabus :
Cet opérateur (dynamic_cast) est une bonne illustration de ce que l'on appelle le RTTI (Run-Time Type Information) proposé par les compilateurs C++ actuels. Ce service permet d'obtenir des informations sur le type dynamique des objets pointés contenant des méthodes virtuelles (on parle dans ce cas d'objets polymorphes).
Pensez-vous que ça pourrait répondre à ma question? Je trouve que ça parle plutôt du compilateur et de dynamic_cast plutôt que des librairies et du downcast mais bon...

dynamic_cast est l'operateur qui permet de faire du downcasting, c'est le moyen pas la raison. On fait du downcasting quand on se trouve avec un objet dont on sait qu'il est d'un type plus evolué quer le type de base.

L'idée qu'un lib serait mal concu par ce qu'elle impose du downcasting me semble un peu simpliste: les template ne resolvent pas tout ce que résoud le polymorphisme, et de plus il impose que le code soit disponible dans les headers (tant que les compilos ne gereont pas le export) ce qui peut-etre inacceptable.

Le rapport entre Templates et Downcasting correspond à l'alternative (bonne à mon avis) aux objets racines de toutes choses qui sont utilisés comme pierres angulaires aux collections. Grâce à cela, une bonne part de downcasting inutile est réglé en C++. Ils agissent comme un bon sucre syntaxique, et ne corrigent pas vraiment les erreurs de design qui n'ont pas de rapport au fond.

Une lib qui va demander (ou réaliser) à downcaster alors qu'un design mieux réfléchi aurait permi de se reposer sur le polymorphisme d'héritage ... ben je ne trouve pas ça terrible. Les templates ne résolvent rien ; il se limitent essentiellement (relativement au downcasting) à un sucrage syntaxique pour mettre en oeuvre des collections et autres types abstraits.

Des exemples typiques où le downcasting est nécessaire ? Comme l'a dit Loulou, assez rapidement avec des plugins ; surtout quand on doit les présenter les uns aux autres, avant qu'ils ne se mettent à coopérer de façon privilégiée. Je pense aussi au multi-dispatching, pour lequel je n'ai pas croisé de solution C++ n'usant pas du downcasting.

Dans tous les cas, la nécessité du downcasting reste ponctuelle. Quand on démarre (en C++, POO, ...) , 95% du temps on pourrait s'y prendre autrement.

Et +42 à

Citation:

---

Envoyé par Gandalf

dynamic_cast [...] c'est le moyen pas la raison

---

Pour ce genre de choses, export ne servira pas à grand'chose, puisqu'il n'évite pas que l'on doive aussi livrer le code source.

Pour ce qui est de protèger du code, je préfère un bon contrat et un bon juriste qu'un système qui camoufle légèrement le code. En général, quand j'achète une bibliothèque, c'est avec son code source.

Et, pour continuer dans la légère caricature, une classe de conteneur réalisée sans template aura en effet peu de risque d'être utilisée illégalement. Elle aura même peu de risque d'être utilisée tout court...

<troll> Pourtant la VCL résiste et ne veut pas disparaitre -- comprendre ses utilisateurs qui ne veulent pas l'abandonner</>

<Troll> De toute façon, même si ses utilisateurs continuent avec, ce sont ses développeurs qui vont l'abandonner... :twisted: </Troll>

Citation:

---

Envoyé par JolyLoic

<Troll> De toute façon, même si ses utilisateurs continuent avec, ce sont ses développeurs qui vont l'abandonner... :twisted: </Troll>

---

c'est déjà fait... J'y connais pas grand chose, mais il me semble que la VCL a pour excuse d'être développée en Pascal et plus ou moins bindée en C++. Faire des templates en Pascal...

Citation:

---

Envoyé par Luc Hermitte

Je pense aussi au multi-dispatching, pour lequel je n'ai pas croisé de solution C++ n'usant pas du downcasting.

---

Lorsque tu parles de multi-dispatch, tu parle du double dispatch, la spécialisation du design pattern Visitor ? Dans ce cas ce que tu dis m'étonne un peu car ces 2 principes permettent justement d'éviter bien des débordements du style downcast et test de type...

Typiquement pour un arbre, dont il a été beaucoup question, des comportements spécifiques aux types des noeuds traités pourront être obtenus de façon élégante, sûre et sans downcast grâce au pattern Visitor... Maintenant il est vrai que cela reste surtout possible lorsque le designer de l'arbre des visités est le même que celui de la hiérarchie de visiteurs, car il y a un fort couplage. Dans le cas d'une API, je ne sais pas si ça serait applicable.

Pour ma part l'exemple le plus courant que je connaisse d'API obligeant au downcast sont les API XML (Xerces et la couche client Oracle en font partie).

Oui, le double c'est ça.
Faut dire aussi que je n'avais pas énormément cherché et que je m'étais arrété aux implémentations de Loki (Modern C++ Design) qui m'avaient parues tenir la route.