Objet d'un type initialisé avec un autre type.

Salut!

J'ai vu à plusieurs reprise dans la FAQ C++
( http://c.developpez.com/faq/cpp/?pag...urs_covariants
http://c.developpez.com/faq/cpp/?pag...UCTEUR_virtuel )
ce type de déclaration:

Code:

---

A * a = new B;

---

où B dérive de A.

1)Quel est l'intérêt de cette notation?
En effet il est inutile de déclarer "a" comme "new B" puisque son type est A
et donc il ne possède pas les attributs de B.
Ce "tronquage" d'attribut n'est-ce pas du slicing?

2)Pourquoi pas un simple:

Code:

---

B * a = new B;

---

Merci de m'éclairer.

C'est le principe même du polymorphisme d'héritagle.. Ce n'est plus par rapport au type de la variable qu'on sait ce qu'il faut appeler, mais par rapport à l'objet réel qui est derrière.

Citation:

---

Envoyé par La FAQ C++

Dans cet exemple, F1() est redéfinie statiquement par B, c'est à dire que le compilateur utilise le type officiel de la variable pour savoir quelle fonction appeler. Ainsi, si on appelle F1() depuis un objet de type A, ce sera toujours A::F1() qui sera appelé, et si l'objet est de type B ce sera B::F1() indépendamment du fait qu'il peut s'agir d'un pointeur ou d'une référence sur A qui désigne en réalité un objet de type B (cas d'utilisation polymorphique de B).

---

http://c.developpez.com/faq/cpp/?pag...NITION_virtual

Tu pourrais imaginer avoir un tableau de A et d'appeler des méthode print() par exemple qui écrivent des choses différentes selon qu'elles sont des A où des dérivés

Oui mais quand je fais :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

class A{ public: int x; };   class B:public A{ public: int y; int z; };   int main() { A * a = new B; a->y=0; //ligne 62

---

Le compilo,à juste titre,m'indique:

Code:

---

62 C:\DOCUME~1\PROPRI~1\Bureau\main_test.cpp 'class A' has no member named 'y'

---

Donc quel est l'interêt de déclarer "a" en tant que objet de type B si il n'en possède pas les attributs supplémentaires:"y" et "z"?

On sait déjà que B dérive de A donc

Code:

---

B *a=new B;

---

implique que "a" est aussi de type A.

je vais te proposer un exemple

Imagine un vehicule! Tu sais qu'il doit avancer mais tu ne sais pas comment car c'est lié au type précis de vehicule, donc tu as cette classe la :

Code:

---

1 2 3 4 5 6

classe Vehicule { public: virtual void avancer(); };

---

mmaintenant tu as un velo et une voiture (par exemple) qui sont des vehicule. Tu as donc cela :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

classe Voiture : public vehicule { public: void avancer(); };   classe Velo: public vehicule { public: void avancer(); };

---

maintenant tu arrive à un moment dans ton programme ou tu as besoin d'un vehicule pour avancer : tu t'en fous duquel tu as donc ca :

Code:

---

1 2	Vehicule *ve;

---

puis un peu plus loin tu apprends que ce vehicule est une voiture tu as donc ca :

Code:

---

1 2	ve = new Voiture();

---

et quand tu feras

Code:

---

1 2	ve->avancer();

---

ca appeleras la methode avancer de la classe voiture

pour ton erreur c'est parce que A ne connait pas y : ca revient a dire (pour notre exemple) qu'un vehicule ne sait pas quel est la puissance de son moteur (car il n'est pas obligé d'avoir un moteur)

voila j'espere etre clair :)

J'rajouterai juste que, lorsque l'on utilise le polymorphisme d'héritage, notre hiérarchie de classes doit être polymorphique, cad qu'elle doit permettre le polymorphisme...
En général, cela se traduit par des fonction virtuelles/surchargées.

hiko-seijuro:Merci pour ton exemple je perçoit mieux la notion de polymorphisme d'héritage.

Citation:

---

pour ton erreur c'est parce que A ne connait pas y : ca revient a dire (pour notre exemple) qu'un vehicule ne sait pas quel est la puissance de son moteur (car il n'est pas obligé d'avoir un moteur)

---

Donc on perd les attributs de la classe voiture! 8O
On n'a que accés à la méthode "avancer".

Donc un

Code:

---

Voiture *ve=new Voiture;

---

est mieux.

J'ai dû mal à voir l'intérêt du polymorphisme d'héritage. :roll:

Auriez vous un exemple où celui ci est nécessaire et où on garderait les attributs de chaque classe?

Merci.

bah oui et non !!


tu sais que tu as besoin d'un vehicule à un instant t mais tu ne sait pas encore quel type de véhicule
(en gros tu sais avancer mais pas comment) et c'est seulement plus tard que le type va se decider dynamiquement bah la c utile

Donc dans les exemples tirés de la FAQ l'utilisation du polymorphisme d'héritage est bidon puisque on connait le type précis de l'objet à sa déclaration?

Le gros principe de l'héritage public, c'est que les objets des classes filles peuvent être utilisés là où l'on attend un objet du type parent. (google/recherche avancée -> LSP)

Ce qui compte dans la fonction qui attend un objet du type parent, c'est ce que l'on peut faire avec le parent. Pas ce que l'on peut faire avec les enfants. On s'en fout.

Quand tu écris tes idées, tu te fiches de savoir si tu écris avec un stylo plume, un crayon, ou un clavier. Ce qui compte c'est que tu as écris des phrases. Juste au début, tu choisis avec quoi tu vas coucher tes pensées (terminologie info, le choix passe via une "factory"). Après, tu couches tes pensées avec une chose qui permet de le faire. Le processus est toujours le même. Pensées -> phrases -> mots -> signes -> couchage de signes. L'élement retenu (stylo/kbd/...) va s'occuper lui du "couchage de signes". L'algo complet se fiche de savoir quel est l'objet exact utilisé. Il sait juste que l'objet fournit le service "coucher_signe(signe)".


Et oui, les exemples de la FAQ font du condénsé. Imagine que tu as un switch (factory rudimentaire), où seront réalisées l'allocation et l'affectation.

merci luc j'arrivai plus à m'expliquer :d

Je commence à mieux cadrer les principes du polymorphisme d'héritage.

Citation:

---

Ce qui compte dans la fonction qui attend un objet du type parent, c'est ce que l'on peut faire avec le parent. Pas ce que l'on peut faire avec les enfants. On s'en fout.

---

Donc le polymorphisme d'héritage est limité.

N'existe t'il pas un moyen d'en faire et au moment de la "précision"(voiture ou vélo) de l'objet pouvoir utiliser les attributs supplémentaires de cet objet(moteur ou pas)?

Si.
Fais une recherche sur le Downcasting sur le forum.
EDIT : http://c.developpez.com/faq/cpp/?rechercher=downcast

Le downcasting est 90% du temps la preuve d'une erreur de design. Ici cela le serait.

En effet. Je confirme.
Nombreux sont les cas que j'ai vus où la personne avait en effet fait une erreur de design. En fait, tous, je crois.
Il y a toujours mieux : genre utiliser le PImpl au lieu d'hériter, utiliser une liste de au lieu d'hériter, pleins de choses de ce genre.
Donc dans le cas ou l'on a besoin de faire quelque chose de spécifique à UNE des classes filles dans un code polymorphique, c'est que le code ne doit pas être polymorphique ... donc problème. CQFD

hiko-seijuro très bon exemple!

Merci de toute vos réponses.

Donc le downcasting est l'inverse du slicing:
on rajoute des caractéristiques à l'objet au lieu d'en tronquer.

Donc si j'ai bien compris le polymorphisme d'héritage sert à manipuler des objets dont seulles nous interresse les méthodes mais où ses particularités n'ont aucune importance.

Citation:

---

Envoyé par seriousme

Donc le downcasting est l'inverse du slicing:
on rajoute des caractéristiques à l'objet au lieu d'en tronquer.

---

le downcasting est plutôt l'inverse du upcasting.
Le slicing c'est autre chose, c'est créer une copie tronquée d'un objet, alors que le downcasting ne fait que réévaluer le type d'un même objet (l'objet pointé par A *a est en fait un B). On ne rajoute pas de caractéristiques à un objet existant, car cet objet les possède déjà. On fait juste en sorte d'y accéder.

Après y'a 2 types d'héritage : structurel (les données membres) et comportemental (les fonctions). C++ mélange les 2.
Mais en gros dans le cas de la virtualité, c'est plutôt le 2° qui intervient. La classe de base sert à définir un contrat (les fonctions virtuelles) = une interface générale commune à toutes les classes de base. Les classes filles implémentent ce contrat, ce qui permet au code client de les utiliser sans même savoir que ces classes de base existent.
Pour reprendre l'exemple, le client va manipuler la classe Voiture sans même savoir qu'il s'agit en fait de la classe RenaultClio ou Peugeot207.

Citation:

---

On ne rajoute pas de caractéristiques à un objet existant, car cet objet les possède déjà

---

pas vraiment:
quand on fait:

Code:

---

vehicule *ve;

---

l'objet pointé par "ve" n'a QUE les caractéristiques de la classe vehicule.

puis:

Code:

---

ve=new voiture();

---

lui en rajoute vraiment:moteur par exemple.

Non. Quand on fait

Code:

---

vehicule* ve;

---

il n'y a aucun objet pointé par ve. :wink:

je dirait plutot que pour

Code:

---

Vehicule *ve

---

tu signales que tu as besoin d'un vehicule !

et avec ca :

Code:

---

ve = new Voiture;

---

tu indique que le vehicule est en fait une voiture

Donc en indiquant que c'est une voiture on rajoute des caractéristiques,le moteur par exemple.

Citation:

---

Non. Quand on fait
Code:
vehicule* ve;
il n'y a aucun objet pointé par ve.

---

Exact.

pour utiliser les caractéristiques il faut que tu cast sinon il ne voit que les caractérisitques d'un vehicule mais en revanche il utilise la méthode spécifique liée à la voiture

Citation:

---

pour utiliser les caractéristiques il faut que tu cast

---

Donc en downcastant on rajoute réelement des caractéristiques.
On n'accéde pas à des caractéristiques existantes mais "cachées" précedemment.

ouaip en gros c ca :)

Non. On ne rajoute rien du tout en downcastant, on se rappelle qu'elles sont présentes. C'est tout.
(Et encore, à la condition que cela soit downcastable dans le type fils en question.)

Si A, B, C et D dérivent de M. Que tu as une fonction f qui travaille sur un M. Si dans la fonction tu te dis que si l'objet m est downcastable en un A, alors tu auras accès à des champs propres à A. Tu as tout faux. Parce que tu feras pareil pour B, C, D, et dans six mois pour E et F qui ne sont pas encore définies. Définir des fonctions polymorphes pour ignorer le polymorphisme n'a aucun intérêt. Tu as toutes les chances d'avoir un mauvais design.

Code:

---

Vehicule *ve=new Voiture();

---

note qu'il y a un upcasting implicite:

Code:

---

1 2	Voiture *v=new Voiture(); Vehicule *ve = static_cast<Vehicule*>( v );

---

avec le downcasting tu fais le chemin inverse pour récupérer v (qui a été perdu) à partir de ve.
note que le cast porte sur le pointeur (dont le type change), mais pas sur l'objet pointé (qui reste toujours le même quel que soient les pointeurs qui le designe).

Citation:

---

note que le cast porte sur le pointeur (dont le type change), mais pas sur l'objet pointé (qui reste toujours le même quel que soient les pointeurs qui le designe).

---

Donc comme le dit Luc Hermitte on a bien accés à des données qui étaient présentes mais "cachées" à cause de la nature du pointeur?
On ne touche pas à l'objet pointé en "l'agrandissant".

Sa place en mémoire n'est pas modifiée effectivement....
Si par exemple tu fait un dynamique_cast ça ne va pas réalouer de la mémoire pour 'rajouter' ce qu'il n'y a pas dans une class mere pour en faire une class fille...
L'intérêt du polymorphisme est justement la....
Voir par exemple le design patern factorie, la class factorie sait qu'elle va construire des véhicules (pour reprendre l'exemple du début), mais elle ne sais pas ce que c'est qu'un vélo, ou une voiture.... Donc la factorie elle retourne des véhicules, c'est l'utilisateur qui définie dans la factorie quel type de véhicule c'est, vélo, voiture, camion...

Merci de ces explications.