Changer le type non-primitif d'une variable/pointeur

J'ai un code dont les classes A,B,C héritent de X.

Comment changer un pointeur

Code:

---

X* pointeur

---

en pointeur sur A ?

Code:

---

1 2	A* pA = static_cast<A*>(pointeur);

---

Par contre fais en sorte d'être assuré que pointeur pointe bien vers un A.

Salut,

Tu as trois possibilités, de la plus sécurisante à la plus potentiellement problématique:

• Le dynamic_cast qui s'utilise sous la forme de
  
  Code:

  ---

  B* b = dynamic_cast<B*>(instance_de_X*);

  ---

  qui effectue une vérification dynamique du type réel, et qui empeche d'obtenir une instance moins bien "cv-qualifiée" (on peut augmenter la "cv-qualification", mais pas la descendre) que l'instance d'origine
• le static_cast qui s'utilise sous la forme de
  
  Code:

  ---

  B* b = static_cast<B*> (instance_de_X*);

  ---

  qui ne vérifie pas a priori si tu peux effectivement transtyper ton instance de départ en autre chose, mais qui empêche une instance moins bien "cv-qualifiée" que l'instance d'origine, et
• le transtypage "C style", sous une forme proche de
  
  Code:

  ---

  B* b = (B*) instance_de_X*;

  ---

  qui n'effectue aucune vérification et qui, en outre, n'empeche pas d'obtenir une instance non constante au départ d'une instance cv-qualifiée.

En outre, il faut être conscient du fait que, non seulement static_cast et dynamic_cast sont plus sécurisés à l'emploi, mais ils facilitent également la recherche dans le code...

En effet, étant donné que l'on utilise les parenthèses et l'étoile * à toutes les sauces en C++, tu risque de devoir passer pas mal de code en revue avant de trouver le transtypage (B*)x; qui t'intéresse :P :aie:, alors qu'une recherche sur static_cast ou dynamic_cast t'amènera beaucoup plus vite sur la partie recherchée :D

Enfin, il peut être utile de se demander si tu n'es pas face à un problème de conception lorsque tu as besoin d'un transtypage allant d'une classe mere à une classe fille...

En effet, dans la plupart des cas - et nous nous comprenons sur ces termes: ils indiquent qu'il ne s'agit pas d'une règle absolue ;) - tu utilisera un pointeur de type de la classe mère pour pouvoir représenter n'importe quel type dérivé... en le faisant passer pour une instance du type de la classe mère.

*Normalement*, tu ne devrais donc essayer d'accéder qu'à des méthodes propres à la classe mère ;)

Si tu souhaites effectuer une action particulière en fonction du type réel dérivé, tu peux te tourner vers la surcharge (ou redéfinition) de fonction (virtuelle), le pattern visiteur ou le pattern "chaine de responsabilité" qui te permettent d'obtenir quelque chose de bien plus évolutif ;)

Merci beaucoup

Chez moi le transtypage "C style" est rejeté par le débugger, du moins tel que je l'utilise :

Code:

---

(B*)instance_de_X*;

---

Peux tu conserver le nom du pointeur ???

Code:

---

1 2 3

Mere* pX = new Mere(); pX = dynamic_cast<Fille>(px);

---

Mon debugger accepte mais quand je vérifie, le type est inchangé.

NB :

Code:

---

1 2	pX = dynamic_cast<File*>pA;

---

se lit convertir pX en type fille ==> (pA)

Bonsoirs,

Citation:

---

Peux tu conserver le nom du pointeur ???

---

Non c'est impossible. Le C++ étant un langage a typage fort, une variable ne peut avoir qu'un type, et ne peut pas en changer. Il faut donc un nouveaux pointeur, pour avoir un nouveaux type.

Citation:

---

pX = dynamic_cast<File*>pA;
se lit convertir pX en type fille ==> (pA)

---

j'aurai plutôt dit:
Convertir pA en type Fille*, et stocker le résultat dans pX

Citation:

---

Le C++ étant un langage a typage fort, une variable ne peut avoir qu'un type, et ne peut pas en changer.

---

Ça n'a rien à voir avec le typage fort, c'est à cause du typage statique.

Si tu as besoin de downcaster, c'est que tu as sûrement un problème de conception.

En fait ma conception est assez simple, j'espère que tu pourras m'aider.


J'ai une bibliothèque musicale avec : des cds, des vinyls, des mp3.

J'ai une classe mère : Support.class (=0 pour abstraite)
Ensuite deux classes filles : Physique.class (=0) et Digital.class (=0)

Et des classes instanciables héritant de Physique.class :
Cd, Vinyl, Cassette, ...

Et pareil pour Digital.class :
mp3, wav, aiff...

TOUTES CES CLASSES comportent une info très importante :
quelle machine va les jouer ?
(ex: platine CD dans CD.class, magnéto dans K7.class, iPod dans MP3.class...)

Ce qui rend Support.class abstraite, c'est que je n'ai pas encore spécifié le lecteur. J'ai donc aussi une arborescence de lecteurs (tous concrets),
qui va de "lecteurs.class" à toutes les filles : platine, turntable, magnéto, ipod, ...


__________
Conclusion :
Support.class =0 spécifie une instance de lecteur.class, mais elle va demander une meilleur spécification et devient par là abstraite : getLecteur() =0

Physique.class =0 garde getLecteur()=0, et ne change que l'apparence graphiques, des détails.
CD.class concrétise getLecteur().

PROBLEME : getLecteur() à la base devrait se trouver dans le constructeur de Support.class, ce qui est impossible.
J'ai donc pallié à ca en INSTANCIANT un lecteur dans Support.class, et en le RE-INSTANCIANT dans CD.class, Vinyl.class, K7.class, etc.

C'est à ce moment que le dynamic_cast intervient.

NB : ca compile et ca exécute.
Mais la remarque de loufoque m'intéresse beaucoup.

Citation:

---

PROBLEME : getLecteur() à la base devrait se trouver dans le constructeur de Support.class, ce qui est impossible.

---

Pourquoi forcément appeler ça dans le constructeur, et non pas dans une fonction d'initialisation que l'utilisateur devrait appeler ?

C'est vrai :?

Mais ce que je viens de noter, c'est que getLecteur() renvoi des types différents : Lecteur, iPod, Platine...

Ca ressemble à une histoire de templates,
est ce que c'est ca ?
est ce que c'est faisable de créer une méthode "template" dans une classe ?

Non, il n'y aura pas de templates pour cela.

Par contre, il y aura une classe abstraite Lecteur, dont hériteront les autres...

J'ai une classe concrète Lecteur dont héritent les autres.

Agréable découverte :
on peut overrider une methode virtuelle pure, et changer son type de retour :

Code:

---

1 2 3 4 5

class Abstraite : Lecteur* getLecteur() =0; class Fille : Magneto* getLecteur();   avec Magnéto héritant de Lecteur.

---

Confirmez vous ?

Citation:

---

Envoyé par ttone

J'ai une classe concrète Lecteur dont héritent les autres.

Agréable découverte :
on peut overrider une methode virtuelle pure, et changer son type de retour :

Code:

---

1 2 3 4 5

class Abstraite : Lecteur* getLecteur() =0; class Fille : Magneto* getLecteur();   avec Magnéto héritant de Lecteur.

---

Confirmez vous ?

---

Nous confirmons, il s'agit de ce que l'on appelle le "retour co-variant"...

La seule restriction est que, dans ton exemple, Magneto doit hériter de Lecteur