Bonjour, je fais le code suivant :

http://rafb.net/paste/results/00ZbW138.html

Comme vous voyez, j´ai un polymorphisme, avec 2 filles.
Au début du main, je cree un objet fille, que je manipule avec un pointeur mere.

Pour accéder a la méthode aaa() UNIQUE dans fille(), principe contraire du polymorphisme qui veut que chaque fille aie la meme tronche que sa mere, je suis obligé, comme vous voyez, de caster violemment la mere en fille, puis d´utiliser cela.

Question 1) Est ce que je ne risque pas ici de la perte de donnée, un mauvais cast ? Est on sur que la méthode aaa() appelée sera a la bonne adresse ?

Question 2) Serait il possible d´éviter le cast dans le main, genre pouvoir faire un truc comme la ligne commentée :
fille* f = m->aaa();

Ou alors :
fille* f = m->get()->aaa();

Avec donc une méthode get() dans la classe mere ( forcément) qui me renvoie finalement, selon la forme polymorphe, un fille* ou un fille2* ? ?

j´ai essayé de faire :
virtual mere* get()=0; dans la mere
et
fille* get(); dans la fille
et
fille2* get(); dans la fille2

mais il m´emmerde sur le fait que ce n´est pas les memes fonctions.

Bref, ce serait surtout pour éviter a l´utilisateur de faire des casts ! je prefere les faire dans les méthodes pour que l´utilisation ultérieure soit simple et fiable ! !
( PS : j´ai pensé aussi a l´héritage, mais j´ai besoin de stocker un pointeur sur la mere, donc je ne peux pas)

Ah ! petite erreur !
Comme aaa() renvoie void, il est évident que je ne peux pas faire :

fille* f = m->get()->aaa();
mais :
m->get()->aaa(); directement.

ah, le probleme du up-casting...

En fait, en C++ ( comme en java d´ailleurs) tu n´es jamais censé avoir besoin de type-caster ers un type plus évolué.
en effet, si tu fais un traitement sur un objet mere pourquoi voudrait tu avoir besoin d´appeler la méthode aaa ?

Si cette méthode devrait pouvoir être appele d´un objet mere, alors elle doit definir la fonction aaa.

Tu n´a pas ici un probleme de langage mais bien un probleme de conception...

en outre, C++ te permet quand meme de faire de l´upcasting et il te permet meme de le faire tres tres proprement a travers ce que l´on appele les RTTI ( run-time type information)
c´est une option a activer a la compilation qui je penses coute des ressources ( mais je ne sais ni quoi ni combien).

cette option te permet de faire
mere* m = new fille();
fille* f = dynamic_cast<fille*> m; / /ici f vaut m
fille* f2 = dynamic_cast<fille2*> m; / /ici f2 vaut NULL

ca peut etre pratique dans certain cas. mais je continue a dire que si tu as besoin d´upcaster, c´est qu´il y a un probleme de fond dans ta modelisation.

Peut etre une erreur de conception.

Mais dans ce cas, j´aimerais ton avis :

J´ai une classe mere " Courbe"
C´est une Courbe, de façon générale.

Dans cette courbe, je veux stocker, soit :
- des cercles
- des nurbs
- des lignes

Donc mon idée était de faire ces 3 courbes spécifiques comme classe fille, en dessous de " Courbe"

Ce que je veux, c´est stocker des Courbe* ailleurs : en effet, si j´imagine une entité " Face", je veux pouvoir stocker comme frontiere, pour découper la face, un tableau de courbes...
Ces courbes peuvent etre aussi bien un arc de cercle qu´une ligne qu´une NURBS, etc ! ! D´ou mon idée de faier une classe mere !
Maintenant, ma classe cercle contiendra un rayon, je veux un accesseur dessus. GetRayon()
ma classe ligne contiendra 2 points, je veux un accesseur GetPoints() dessus par exemple !
Tu vois, chaque fille a des méthodes spécifiques !

Que me proposerais tu comme façon de concevoir ? ( et les autres ? )

je n´ai pas dit qu´elle ne devait pas avoir des methodes specifique.

En fait tu te retrouve devant un probleme
d´interface. La question c´est: " quel est le comportement d´une courbe ? Qu´est ce que je peux faire avec une courbe ? "
Si la reponse a cela est: " je veux l´afficher"

alors tu dois fournir dans courbe une fonction:
void paint ( BufferAffichage); / / affiche la courbe sur le buffer
ou
void paint ( Coord2D* buffer, int bufsize); / /renvoye un tableau de point

et apres, tu va polymorpher ces fonctions et c´est la que tu utilisera tes GetRayon et cie...

oui, mais pour utiliser GetRayon et cie, justement, je suis obligé de caster dans le main !
Que me proposes tu comme idée pour éviter cela ?

je ne m´y connait pas trop en POO, particulièrement avec les concept avancé.

Mais si j´avais à faire ça et que je voulais m´en titer sans POO justement je ferais un truc dans le genre :

class Courbe
{
enum
{
cercle,
nurb,
ligne
} type;
union
{
ligne l;
nurb n;
cercle c;
} courbe;
};

les trois classe ligne, nurb et cercle pouvant si nécessaire dériver d´une même classe.

Je ne sais pas si c´est une bonne méthode, mais c´est pas trop compliqué.

union, j´avais déja pensé, mais ce n´est vraiment pas conseillé d´en mettre dans les classes, c´est ultra sale...
Ah lala je désespere... personne n´a une méthode ?

bon, je la refait

class courbe
{
public void paint(BufferAffichage) = 0;
}

class arcCercle
{

public Coord2D getOrigine(){...}
public paint(BufferAffichage ba)
{
/ /ici je peux faire un getOrigine
}
}

godrik >
je vois le probleme de vectoriel : je pense que ta classe obligerait quand meme de caster :

car si tu fais :

courbe* c = new arcCercle()

alors tu peux faire c->paint pour appeler la méthode de arcCercle, mais pour appeler la méthode
GetOrigine(), tu es obligé de caster :
si tu fais :

c->GetOrigine(); il va gueuler...

J´ajoue que je ne vois pas comment faire ! Moi aussi je suis curieux de voir les idées qu´il y aura sur ce topic !

nan mais c´est juste mal!
Tu dois definir une interface courbe a travers laquelle tu va te servir de tes objets.

tu dois te foutre completement de l´implémentation de cette interface.
en d´autre terme, a partir du moment ou tu as down caster, tu ne dois plus avoir besoin que de ce qui est disponible dans l´interface!