Discussion :

[beegees]

Bonjour tout le monde,

J'ai une classe nommée CTableauGenerique.

Dans un de mes exercices, on crée un objet de ce type là, mais s'est la suite que je ne comprends pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CTableauGenerique	TabVehicules((const CGenerique&)CTabVehicules())

Sauriez-vous m'expliquez ce que s'est ?

Je vois qu'il y'a un cast (CGenerique&) mais CTabVehicules() me trouble...

Merci d'avance pour votre aide.

beegees

[droggo]

Gia,

Comme pour ton autre sujet, va voir la classe CTabVehicules.

a priori, elle dérive de CGenerique.

[beegees]

Gia,

Comme pour ton autre sujet, va voir la classe CTabVehicules.

a priori, elle dérive de CGenerique.

Bonjour,

Il me semble que s'est plus compliqué que pour mon premier message, non ?

Merci pour ton aide.

beegees

[Davidbrcz]

Ta vraiment un problèem avec la création d'objet !
CTabVehicules() crée un objet de type CTabVehicules en appelant le constructeur par défaut.Ensuite on cast cet objet en référence constante de type CGenerique pour passer le tout au constructeur de TabVehicules, appellé en tant que constructeur d'une classe mère.

[koala01]

Salut,

Si le code est généralement lu de gauche à droite, il est, le plus souvent à interpréter... de droite à gauche

Ainsi, la première chose qui sera effectivement faite dans une expression complexe, c'est celle qui se trouve à l'extrème droite de l'expression (du moins, quand il ne s'agit pas d'un test, on est bien d'accord )

En effet, le comportement indiqué par Davidbrcz est bel et bien le comportement observé, et voici la raison:

• CTabVehicules() : appelle le constructeur par défaut de la classe de CTabVehicules (car il faut bien un objet pour arriver à le caster )
• (const CGenerique&) caste (ce qui suit) en une référence constante sur un objet de type CGenerique
• la parenthèse ouverte avant le (const CGenerique&) et fermée apres le CTabVehicules() regroupes les informations à passer au constructeur de CTableauGenerique
• L'objet construit pend le doux nom de TabVehicules, et, enfin, en début de ligne, on retrouve le type de l'objet à construire

Ceci dit, ce code est de nature à souvlever énormément de questions, et à e faire hurler plus d'un "puriste"...

D'abord à cause du fait que c'est un cast "C style" qui est utilisé:

Ce genre de transtypage permet tout, y compris le pire.
On ne peut en effet jamais être sur que l'objet à transtyper est compatible, du point de vue de l'utilisation de la mémoire, avec l'objet dans lequel il doit être transtypé...

On préférera le plus souvent utiliser une méthode plus "controlée" du C++ telle que le static_cast ou le dynamic_cast
Ensuite, parce que l'on peut se poser la question de l'utilité même du transtypage.

En effet, le code semble indiquer que la classe CTabVehicules est compatible (et sans doute dérive) de la classe CGenerique.

Si ce n'est pas le cas, tu comprendra les risques encourus par le transtypage "C style" (et on pourrait se poser la question de savoir pourquoi ce n'est pas le cas), et, par contre, si c'est le cas, il faut savoir que l'objet créé est d'office un objet constant, et peut très bien faire office de référence constante sur un objet de la classe parent... ce qui rend le transtypage parfaitement inutile

En effet, les objet temporaires (tels que ceux créé spécifiquement pour servir d'argument passé à une fonction) ne peuvent s'intégrer que dans des fonctions pour lesquels l'argument est demandé sous forme de référence constante, ce qui *semble* etre le but du transtypage

[beegees]

Ta vraiment un problèem avec la création d'objet !
CTabVehicules() crée un objet de type CTabVehicules en appelant le constructeur par défaut.Ensuite on cast cet objet en référence constante de type CGenerique pour passer le tout au constructeur de TabVehicules, appellé en tant que constructeur d'une classe mère.

Bonjour Davidbrcz,

Un tout grand merci pour ta réponse.

Jamais je n'aurais trouvé cela sans toi

Encore un tout grand merci.

beegees

Salut,

Si le code est généralement lu de gauche à droite, il est, le plus souvent à interpréter... de droite à gauche

Ainsi, la première chose qui sera effectivement faite dans une expression complexe, c'est celle qui se trouve à l'extrème droite de l'expression (du moins, quand il ne s'agit pas d'un test, on est bien d'accord )

En effet, le comportement indiqué par Davidbrcz est bel et bien le comportement observé, et voici la raison:

• CTabVehicules() : appelle le constructeur par défaut de la classe de CTabVehicules (car il faut bien un objet pour arriver à le caster )
• (const CGenerique&) caste (ce qui suit) en une référence constante sur un objet de type CGenerique
• la parenthèse ouverte avant le (const CGenerique&) et fermée apres le CTabVehicules() regroupes les informations à passer au constructeur de CTableauGenerique
• L'objet construit pend le doux nom de TabVehicules, et, enfin, en début de ligne, on retrouve le type de l'objet à construire

Ceci dit, ce code est de nature à souvlever énormément de questions, et à e faire hurler plus d'un "puriste"...

D'abord à cause du fait que c'est un cast "C style" qui est utilisé:

Ce genre de transtypage permet tout, y compris le pire.
On ne peut en effet jamais être sur que l'objet à transtyper est compatible, du point de vue de l'utilisation de la mémoire, avec l'objet dans lequel il doit être transtypé...

On préférera le plus souvent utiliser une méthode plus "controlée" du C++ telle que le static_cast ou le dynamic_cast
Ensuite, parce que l'on peut se poser la question de l'utilité même du transtypage.

En effet, le code semble indiquer que la classe CTabVehicules est compatible (et sans doute dérive) de la classe CGenerique.

Si ce n'est pas le cas, tu comprendra les risques encourus par le transtypage "C style" (et on pourrait se poser la question de savoir pourquoi ce n'est pas le cas), et, par contre, si c'est le cas, il faut savoir que l'objet créé est d'office un objet constant, et peut très bien faire office de référence constante sur un objet de la classe parent... ce qui rend le transtypage parfaitement inutile

En effet, les objet temporaires (tels que ceux créé spécifiquement pour servir d'argument passé à une fonction) ne peuvent s'intégrer que dans des fonctions pour lesquels l'argument est demandé sous forme de référence constante, ce qui *semble* etre le but du transtypage

Salut Koala01,

Un super grand et sincère merci pour ta réponse qui m'aide énormément.

Jamais je n'aurais trouvé sans votre aide !

Comme je l'ai dis, pour l'instant j'ai énormément de mal et l'examen approche à grand pas.

Ton explication est claire et précise, complète et très détaillée.

Il y'a quand même une question que je me pose :

à quoi sert de faire un tel objet ?

As-tu besoin de l'ensemble de mon code pour répondre à cette question ?

Je vais essayer de répondre à au moins une de tes questions :

Koala dit :

Ensuite, parce que l'on peut se poser la question de l'utilité même du transtypage.

Voici ce que le Prof dit sur CTableauGenerique TabVehicules((const CGenerique&)CTabVehicules());

Je vais créer une variable de type CTableauGénérique que j'appelle TabVehicules et en fait
Dans ce tableau là les éléments seront des CTabVéhicules donc dans l'objet poubelle ça doit être CTabVéhicules, malheureusement comme CTabVéhicules hérite avant tout de CTableauGénérique avant d'hériter de CGénérique là j'utilise le constructeur par copie de CTableauGénérique si je veux lui préciser que cet objet là s'est pas une source, une copie mais le model objet poubelle je dois faire une conversion pour dire non "ça s'est un objet générique" et là il utilisera le bon constructeur, le constructeur spécifique qui prend le modèle de poubelle en paramètre donc là il n'essaiera pas de dupliquer les données de tableau vide CTabVéhicules qui est là mais il considérera que s'est mon objet poubelle.

Voilà, encore meric pour ton aide, en espèrant encore avoir de tes nouvelles.

Beegees

[koala01]

<snip>
Il y'a quand même une question que je me pose :

à quoi sert de faire un tel objet ?

Il s'agit, tout simplement, de mettre en oeuvre ce que l'on appelle le polymorphisme.

En effet, si un type particulier hérite - comme un CTabVehicules - (dérive) d'un type plus "générique" - comme CGenerique - tu peux faire passer les objets du type particulier pour des objets du type générique.

En redéfinissant certaines méthodes qui existent pour le type générique dans le type particulier, tu peux faire de manière à ce que le comportement observé lors de l'appel de ces méthodes corresponde au comportement que l'on attendrait de la part du type particulier.

As-tu besoin de l'ensemble de mon code pour répondre à cette question ?

Idéalement, j'aurais besoin d'avoir un aperçu de l'ensemble de l'arbre d'héritage... pour être tout à fait précis.

Mais, si tu peux déjà simplement me dire si j'interprète bien ce que tu écris en disant que

• la classe CGenerique est une classe de base dont héritent toutes les autres
• La classe CTableauGenerique hérite de CGenerique,
• la classe CTableauVoiture hérite de CTableauGenerique
• il existe sans doute une classe CVoiture qui hérite de CGenerique (mais pas de CTableauGenerique)

Je vais essayer de répondre à au moins une de tes questions :



Voici ce que le Prof dit sur CTableauGenerique TabVehicules((const CGenerique&)CTabVehicules());

Je vais créer une variable de type CTableauGénérique que j'appelle TabVehicules et en fait
Dans ce tableau là les éléments seront des CTabVéhicules donc dans l'objet poubelle ça doit être CTabVéhicules, malheureusement comme CTabVéhicules hérite avant tout de CTableauGénérique avant d'hériter de CGénérique là j'utilise le constructeur par copie de CTableauGénérique si je veux lui préciser que cet objet là s'est pas une source, une copie mais le model objet poubelle je dois faire une conversion pour dire non "ça s'est un objet générique" et là il utilisera le bon constructeur, le constructeur spécifique qui prend le modèle de poubelle en paramètre donc là il n'essaiera pas de dupliquer les données de tableau vide CTabVéhicules qui est là mais il considérera que s'est mon objet poubelle.

<snip>

Tu devrais conseiller à ton prof:

• d'utiliser de préférence le static_cast pour ce qu'il veut faire (static_cast<type_destination>(type_origine) )
• de rendre le constructeur par copie de CTableauGenerique privé, et
• d'implémenter une méhtode statique y faisant appel pour autoriser la copie de l'élément (mais est-ce réellement utile, n'est il pas plus intéressant d'interdire la copie du tableau ) ce qui aurait l'avantage
• d'éviter l'ambiguité entre le constructeur prenant un objet de type CGenerique et le constructeur par copie, ou de réfléchir à la possibilité que
• un objet CTableauGenerique soit construit, par défaut vide, et remplis par une méthode ad-hoc

Tu pourrais aussi sussurer à l'oreille que, quoi qu'il en soit, il y a peut etre un défaut de conception dans son histoire

[beegees]

Il s'agit, tout simplement, de mettre en oeuvre ce que l'on appelle le polymorphisme.

En effet, si un type particulier hérite - comme un CTabVehicules - (dérive) d'un type plus "générique" - comme CGenerique - tu peux faire passer les objets du type particulier pour des objets du type générique.

En redéfinissant certaines méthodes qui existent pour le type générique dans le type particulier, tu peux faire de manière à ce que le comportement observé lors de l'appel de ces méthodes corresponde au comportement que l'on attendrait de la part du type particulier.

Idéalement, j'aurais besoin d'avoir un aperçu de l'ensemble de l'arbre d'héritage... pour être tout à fait précis.

Mais, si tu peux déjà simplement me dire si j'interprète bien ce que tu écris en disant que

• la classe CGenerique est une classe de base dont héritent toutes les autres
• La classe CTableauGenerique hérite de CGenerique,
• la classe CTableauVoiture hérite de CTableauGenerique
• il existe sans doute une classe CVoiture qui hérite de CGenerique (mais pas de CTableauGenerique)

Tu devrais conseiller à ton prof:

• d'utiliser de préférence le static_cast pour ce qu'il veut faire (static_cast<type_destination>(type_origine) )
• de rendre le constructeur par copie de CTableauGenerique privé, et
• d'implémenter une méhtode statique y faisant appel pour autoriser la copie de l'élément (mais est-ce réellement utile, n'est il pas plus intéressant d'interdire la copie du tableau ) ce qui aurait l'avantage
• d'éviter l'ambiguité entre le constructeur prenant un objet de type CGenerique et le constructeur par copie, ou de réfléchir à la possibilité que
• un objet CTableauGenerique soit construit, par défaut vide, et remplis par une méthode ad-hoc

Tu pourrais aussi sussurer à l'oreille que, quoi qu'il en soit, il y a peut etre un défaut de conception dans son histoire

Resalut Koala,

Merci beaucoup pour ta réponse qui est vraiment bien détaillée.

Il s'agit, tout simplement, de mettre en oeuvre ce que l'on appelle le polymorphisme.

En effet, si un type particulier hérite - comme un CTabVehicules - (dérive) d'un type plus "générique" - comme CGenerique - tu peux faire passer les objets du type particulier pour des objets du type générique.

En redéfinissant certaines méthodes qui existent pour le type générique dans le type particulier, tu peux faire de manière à ce que le comportement observé lors de l'appel de ces méthodes corresponde au comportement que l'on attendrait de la part du type particulier.

Je n'ai jamais eu une explications aussi claire

En plus de ça, tu n'a que très peu d'élément, tu es vraiement très très bon en C++, félicitation et merci !

[QUOTE]Mais, si tu peux déjà simplement me dire si j'interprète bien ce que tu écris en disant que[LIST]

[*]la classe CGenerique est une classe de base dont héritent toutes les autres

Exactement

[*]La classe CTableauGenerique hérite de CGenerique,

Exactement

[*]la classe CTableauVoiture hérite de CTableauGenerique

Exactement

[*]il existe sans doute une classe CVoiture qui hérite de CGenerique (mais pas de CTableauGenerique)

Exactement

trop fort

Il y'a cela aussi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
class CGenerique
{
friend CTableauGenerique;

Donc CTableauGenerique à comme ami CGenerique, il peut donc utiliser tout ce qu'il veut dans CCgenerique même les membres privés ?

Je te laisse mon code (zippé)

Un tout tout grand merci pour ton aide qui est vraiment très appréciée.

Beegees

[loufoque]

caster c'est mal.
Vire donc cette immondice de ton code.

[Davidbrcz]

Mais dès fois ya pas le choix :p.
Mais là je reconnait volontier que ce cast est assez moche

[beegees]

Mais dès fois ya pas le choix :p.
Mais là je reconnait volontier que ce cast est assez moche

As-tu une autre solution ?

Merci
beegees

[Davidbrcz]

Bah disons que tu construit un objet de type CTableauGenerique avec un CTabVehicules en forcant, l'utilisation du constructeur qui prend une référence constante sur un objet de type CGenerique alors que ta classe dispose d'un constructeur approprié (celui de copie) car car ton objet CTabVehicules est un CTableauGenerique.
Le mieux, pour moi c'est donc de le supprimer.

PS: les templates, ca te parle ?
Car là c'est très java-like ( toutes les classes dérivents d'une même classe mère).

[beegees]

Bah disons que tu construit un objet de type CTableauGenerique avec un CTabVehicules en forcant, l'utilisation du constructeur qui prend une référence constante sur un objet de type CGenerique alors que ta classe dispose d'un constructeur approprié (celui de copie) car car ton objet CTabVehicules est un CTableauGenerique.
Le mieux, pour moi c'est donc de le supprimer.

PS: les templates, ca te parle ?
Car là c'est très java-like ( toutes les classes dérivents d'une même classe mère).

OK merci pour cette proposition.

Je suis actuellement devant un très gros problème avec un exercice que je fais sur base de celui-ci.

Merci encore.

beegees

[koala01]

Tu me fais trop d'honneurs...

Disons que, au mieux, j'ai de bonnes capacités d'analyse et d'interprétation de ce que je lis

Pour la question subsidiaire, le fait de déclarer la classe CTableauGenerique amie de la classe CGenerique permet, effectivement, à tout objet de type CTableauGenerique d'accéder à l'ensemble de ce qui constitue un objet de type CGenerique, quelle que soit l'accessibilité (private, protected ou public) du constituant.

Cependant, il faut garder en mémoire le fait que l'amitié n'est ni héritée, ni transitive, ni réciproque, et que donc, si dans la classe CVehicule (ou CTableauVehicules), tu rajoute des membres ou des méthodes protégés ou privés, cela n'autorisera pas les objet de type CTableauGenerique à accéder à ces nouveaux membres et méthodes

[beegees]

Salut Koala,

Tu me fais trop d'honneurs...

Non crois-moi, s'est bien mérité !

Disons que, au mieux, j'ai de bonnes capacités d'analyse et d'interprétation de ce que je lis

Grande qualité pour un informaticien

Pour la question subsidiaire, le fait de déclarer la classe CTableauGenerique amie de la classe CGenerique permet, effectivement, à tout objet de type CTableauGenerique d'accéder à l'ensemble de ce qui constitue un objet de type CGenerique, quelle que soit l'accessibilité (private, protected ou public) du constituant.

Merci pour la confirmation

Cependant, il faut garder en mémoire le fait que l'amitié n'est ni héritée, ni transitive, ni réciproque, et que donc, si dans la classe CVehicule (ou CTableauVehicules), tu rajoute des membres ou des méthodes protégés ou privés, cela n'autorisera pas les objet de type CTableauGenerique à accéder à ces nouveaux membres et méthodes

Merci pour ce point important

En te souhaitant une bonne journée.

beegees