Discussion :

[Ubum]

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 ?
Si oui comment ? Merci.

[Pragmateek]

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.

[Swoög]

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...

[Ubum]

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 ?

[Matthieu Brucher]

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 !

[loufoque]

Tu peux même utiliser static_cast si tu es certain du type.

[zais_ethael]

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).

[Swoög]

Une simple rectification :

Ton champs contenant ta classe mère (ou fille) doit obligatoirement être un pointeur sinon tu l'as dans l'os

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 ^^

[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...?

[Swoög]

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...

[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.

[Swoög]

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++...

[zais_ethael]

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++).

[Swoög]

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 ^^

[zais_ethael]

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?

[Swoög]

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

[zais_ethael]

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)
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.

il faut suivre ses objets

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.
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.

[Swoög]

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 ^^

[zais_ethael]

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 L'HERITAGE !!! C'était justement la question initiale de ce thread.
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

[Swoög]

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