Version imprimable
Salut, je voudrais savoir s il est possible de recuperer une fonction d une classe fille a partir d une classe mere ?.
En gros j ai une reference sur une classe mere qui derive en une classe fille et j ai un champ dans la classe fille qui m interesse. Je peut le recuperer ? :aie:
Si oui comment ? Merci.
A moin de faire du downcasting je sais pas.
Sinon si la classe mère a besoin d'un élément de la classe fille c'est qu'il y a problème de conception.
En effet, je rejoins seriousme, si tu as besoin d'accède au champ d'une classe fille pour une instance que tu considère comme étant de la classe mère, il y a problème...
au mieux, tu n'exploites pas le polymorphisme...
au pire, il y a une mauvaise modélisation quelque part...
Exemple:
class fille derive de mere
Lors de ma creation de ma classe toto on m'impose en constructeur, un constructeur qui prend en argument un champ de type fille mais qui est conservé par la classe dont herite toto (et donc par toto) comme une classe de type mere.
Donc a l'origine il y'a eu transtypage de la classe fille a la classe mere. Est ce impossible de refaire le chemin inverse comme en java ? avec par exemple (fille) champs_de_type_mere ?
C'est possible, avec dynamic_cast, mais c'est pas ce qu'il y a de mieux, comme l'on dit les 2 autres posteurs !
Tu peux même utiliser static_cast si tu es certain du type.
Ben... oui, bien sur, les casting c'est pas pour les chiens.
Sinon deux ou trois objections:
Tu as interet à ce que la classe toto n'aie rien à voir dans le système d'héritage de tes classes mère et fille, sinon il y a un gros défaut de conception comme disent ceux qui m'ont précédé.
Ton champs contenant ta classe mère (ou fille) doit obligatoirement être un pointeur sinon tu l'as dans l'os.
Tu dois être sur que tu accèdes bien à un objet de la classe fille (possible de teste ca avec des castings spéciaux mais c'est pas le top, on peut presque toujours s'en passer).
Une simple rectification :un pointeur OU une référence, les deux cas fonctionneront ;) tant qu'il n'y a pas copie de la variable de base, il n'y a pas de problème en fait ^^Citation:
Envoyé par zais_ethael
Ce n'est pas faux mais je n'utilise que des pointeurs (généralement avec smart pointers) à l'interieur de mes classes, jamais essaye d'y déclarer des réfèrences. Ca doit pas être évident pour gérer quels objets sont contenus par quels autres...?
il n'y a pas que dans le cas de classes... il y a aussi le cas par exemple, ou c'est l'argument d'une fonction etc... ;)Citation:
Envoyé par zais_ethael
Parfaitement, je n'ai jamais dit le contraire.
Mais tu semblais parler d'un stockage de réference dans un objet, approfondis le sujet.
non, pas spécialement, de toutes façons, stocker une référence dans un objet, c'est comme stocker un pointeur constant (T* const)... il n'y a pas de différence excepté la syntaxe... c'est juste plus propre d'un point de vue C++...
Pas vraiment.
Si tu utilises une réference d'un objet A dans un objet B, l'objet réferencé doit bien exister quelque part, probablement dans un objet C. Si tu détruits l'objet C mais pas le B, la réfèrence contenue dans B devient invalide. Il faut donc conserver l'objet A exclusivement dans l'objet B, soit par valeur (ne permet pas l'héritage) soit par pointeur (en détruisant l'objet pointé dans le destructeur de B --> auto_ptr++).
j'ai pas tout compris ce que tu racontes... mais je suis totalement sûr qu'utiliser une référence et un T* const est la même chose... que ce soit au niveau des pointeurs (références) fantômes, que de tous les autres problèmes....
sinon donne moi un exemple où il y a un problème avec une référence qu'il n'y a pas avec un T* const ^^
Je n'en sais strictement rien, je n'utilises pas de pointeurs constant.
Mais si tu me dis qu'ils réagissent de la même facon que les réfèrences, alors le problème est le même.
Un objet contenant une réfèrence (ou un pointeur constant si tu veux) ne "possède" pas l'objet réfèrencé, il ne peut donc pas décider de le détruire. Qui dit qu'il ne peut pas le détruire dit qu'il y a un autre objet qui en a la charge. Donc si l'autre objet décide de détruire l'objet réfèrencé il y a comme un blème....
Tu me suis?
Oui, tout à fait, mais le problème est le même avec un pointeur classique...
si ce n'est que pour le pointeur classique peut-être modifié pour être mis à NULL...
MAIS comme on ne peut pas détécter à l'éxecution les pointeurs fantômes, il faut suivre ses objets... tout comme avec les références ;) il suffit de ne supprimer un objet que quand il devient inutile de manière sûr, normalement, l'objet (A) qui stocke la référence à un autre (R) qui appartient lui-même à un troisième objet (B) implique que A sera détruit avant B donc il n'y aura pas de problème de référence fantôme ;)
Oui, c'est tout à fait possible.
Cela dit dans l'objet B tu est quand même obligé d'utiliser un pointeur (ou d'utiliser un stockage par valeur mais encore une fois pas d'héritage) :lol:
Qui plus est, même si c'est une technique valide ne provoquant pas de fuites ou de pointeurs fantomes il y a une faille: l'interet de la programmation orientée objet est justement de ne pas être obligé d'avoir une vision globale du programme.
Crois moi, tu finis inévitablement par oublier des trucs sur de gros projets, même si tu les a codés personellement de A à Z. Si en plus tu rajoutes de la programmation multi-thread et tout le toutim tu n'es pas sortis de l'auberge.Citation:
Envoyé par Swoög
Utiliser ce genre de procédé ne devrait être fait que pour optimization et si la gestion de tes objets A, R et B est elle-même encapsulée bien à l'abris dans une autre classe.
non, pas besoin de pointeur dans l'objet B... tu déclares une instance normale de ta variable, ainsi elle sera détruite en même temps que l'objet B...
et soit dit-en passant, il est moins plantogène d'"oublier quelque chose" (comme tu dis) en utilisant des références que des pointeurs ;) il y a moins de possibilités d'erreur ^^
ET L'HERITAGE !!! C'était justement la question initiale de ce thread.Citation:
Envoyé par Swoög
Bon, en dehors de ca: J'utilise des réfèrence, mais je ne les conserve pas.
C'est à dire que je m'en sert dans les fonctions sans jamais les stocker dans des objets. A prioris, si je me balade dans mes fonctions avec ma réfèrence, l'objet ne peut pas être supprimé entre temps, donc pas de risque ( quoique c'est différent avec de la programmation multi-thread ). Mais à partir du moment ou je la stocke quelque part, l'objet réfèrencé peut très bien avoir disparu entre temps.
Voici ma facon de procéder:
- pour les types primaires c'est par valeur en permence (à noter que je considère les strings comme type primaire).
- pour les objets je les stocke toujours en temps que pointeur (je fais plus de java que de C++, je n'y peut rien c'est plus fort que moi, je dois toujours considérer la possibilité de l'héritage même sur des classes qu'à prioris je ne ferais jamais hériter) et toujours dans des auto_ptr ou les container de boost
- pour les objets toujours j'utilise les réfèrences du C++ en temps que réfèrences faibles, c'est à dire pour avoir un accès à l'objet sans être responsable de son cycle de vie
En effet.. il faudra demander à un modérateur de couper le topic demain lol ;)
sinon les références ne coupe pas du tout l'accès à l'héritage, tout comme les pointeurs ;)
sinon, perso les objets, je les stockes par valeurs le plus possible plutôt... comme ça, pas besoin de s'embêter avec allocation/désallocation ;)
Essaie les auto_ptr, ils sont justement fait pour ca. Quand aux réfèrences, comme je l'ai dit elles ne se suffisent pas à elles-mêmes pour résoudre les problèmes d'héritage, il faut bien pouvoir gérer le cycle de vie de tes objets.
J'avoue, le manque de sommeil nuit gravement à la santé mentale :DCitation:
Envoyé par Swoög
Vais penser à aller me coucher moi.
Avec un pointeur, c'est tout aussi peu valide, si l'objet C est détruit, normalement l'objet interne pointé aussi...Citation:
Envoyé par zais_ethael
Ok merci ;)
Malheuresement je n'ai pas codé les classes meres donc je doit faire avec.
Je vais essayer ce que vous me proposez.
???
La première chose à faire est le codage des classes mères !
C'est exactement ce que je dis. Idéalement un même objet ne peut être contenu que dans un seul objet à la fois. Ou alors on a une gestion des cycles de vie impecable et très localisée.Citation:
Envoyé par Miles
Mais de toutes facons un objet ne peut pas être désigné que par des réfèrences, il doit forcément être présent à un endroit précis soit par valeur soit par pointeur (deuxième solution indispensable si on veut faire de l'héritage).
Donc on se comprend bien :D
Solution qui marche aussi bien : les smart pointers de Boost :)
Et ouep.
Par contre je trouve aussi l'auto_ptr très utile (les shared_ptr c'est bien joli mais je préfère les utiliser uniquement quand c'est nécessaire). Le plus utile dans boost, je trouve, sont les collections de pointeurs.
J'aime aussi bien les auto_ptr, mais les ppointeurs de boost sont plus adaptés - à la place de l'auto_ptr prendre le scoped_ptr par ex -
C'est quoi ces collections de pointeurs ?
Les pointer containers comme ils disent. C'est des trucs qui calquent le principe des containers de la stl mais utilisent des pointeurs au lieu de stocker par valeur, ils sont pas mal foutus pour faire des collections d'objets.
Faudra que je regarde de plus près, merci pour l'indication :)