Copie d'objet hérité

Bonjour.

J'essaye de copier des objets hérités, mais il semble que l'héritage ne soit pas pris en compte.
J'utilise pourtant que des fonctions virtuelles dans l'objet mère, et transfère l'objet en std::shared_ptr <Objet>.

Voici un bout de code , où "_object_container" contient des objets "Object_HUD", hérités de l'objet mère "Object" :
(j'aurais pus utilisé un froncteur pour chercher dirrectement l'objet par son nom, mais pour l'instant, c'est pas la question)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

std::shared_ptr < Object > model_Object ;   for ( std::vector < std::shared_ptr < Object > > :: iterator it = _object_container.begin() ; it != _object_container.end() ; it ++ ) { if( (*it) -> setName() == name ) {   model_Object = *it ;   }   }   std::vector < std::shared_ptr < Object > > :: iterator it ;   it = find ( _object_container.begin() , _object_container.end() , model_Object ) ;   std::shared_ptr < Object > model ( new Object ( **it )) ;   model -> getPosition ( x , y ) ;   _object_container.push_back ( model ) ;

---

L'objet est bien copié, mais en tant qu'Object, et non "Object_HUD"...

Comme je le disais plus haut, l'objet mère ne contient que des fonctions virtuelles, et l'objet est copié en shared_ptr ...Il me semble donc respecter les condition pour effectuer une copie d'objet hérité...

est-ce donc bien le cas ou j'ai oublié quelque chose / ou ca ne marche pas comme ca avec la copie des objets hérités.

Merci si vous pouvez m'aider.

Pour copier virtuellement, il faut "copier virtuellement".
Pour ce faire, on utilise une fonction virtuelle qui copie l'objet, généralement nommée clone().

Par exemple:

Code:

---

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

class Bidule { public: virtual Bidule clone() const {return Bidule();} };   class SuperBidule : public Bidule { private: int i; public: SuperBidule(int a) : i(a) {} SuperBidule(SuperBidule const& other) : i(other.i) {} SuperBidule operator=(SuperBidule const& other) { i = other.i; return *this;}   virtual SuperBidule clone() const {return *this;} };

---

Merci pour votre réponse.

Cela me semble être en effet la bonne solution, cependant, quand je tape ce code, il me dit :

"error: invalid covariant return type for 'virtual Object_HUD Object_HUD::clone() const'
"error: overriding 'vitrtual Object Object::clone() const'

voici mes 2 objets :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

class Object {   public :   Object ( ) ; ~Object ( ) ;   virtual Object clone() const { return Object() ; } ...   protected :   ... };   class Object_HUD : public Object {   public :     Object_HUD(){} Object_HUD( Object_HUD const& other ){} Object_HUD operator = ( Object_HUD const& other ) { return *this ; }   Object_HUD clone() const { return *this ; }   protected:   ... };

---

Ais-je oublié quelque chose ?

Les retours covariants c'est avec des pointeurs ou des références.

Passes tes opérateurs de copie en protégé et utilises unique_ptr<Object> :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

struct Object { virtual std::unique_ptr<Object> clone() const { return std::make_unique<Object>(*this) ; } virtual ~Object() {}   protected : Object(Object const & rhs) { /*stuff*/ } };   struct Object_HUD : Object { std::unique_ptr<Object> clone() const { return std::make_unique<Object_HUD>(*this); }   protected: Object_HUD(Object_HUD const & rhs) { /*stuff*/ } };

---

Merci pour la correction.
Ca fait longtemps que je n'avais plus écrit un clone...

En passant par des fonctions libres, il y a moyen d'émuler des retours covariants tout en renvoyant des pointeurs intelligents. Cf ce très récent article qui détaille la démarche: http://cppcodereviewers.com/covarian...mart-pointers/

Oui, ca marche ! ( j'ai plutôt utilisé un std::shared_ptr <Object> dans mon cas, mais le resultat est le même )

Merci pour vos réponses !

Pour une opération de création de nouvel objet, std::unique_ptr a beaucoup plus de sens. C'est une fonction source.

Et si l'objet est destiné à être un shared_ptr ?

Ca ne change absolument rien.

Ok, merci.

J'ai une autre question, toujours a propos de la copie d'objets :

dois-je recopier systématiquement toutes les variables de l'objet mère dans les constructeurs de copie des objets filles ?
ou existe-t-il une fonction spéciale, comme lors d'une surcharge de fonction :

ex :

Code:

---

1 2 3 4 5 6

void ObjectHéritéDeObject::fonction() { Object::fonction() ; }

---

ceci pourrait-il se faire également dans un constructeur de copie ( afin d'éviter de tout recopier à chaque fois ) :

ex :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

ObjectHéritéDeObject::ObjectHéritéDeObject( ObjectHéritéDeObject const& other ) {   Object::Object ( ??! ) ; ...   _varriable = other._varriable ; _varriablePtr = new VarriablePtr( *( other._varriablePtr ) ) ;   etc...     }   ObjectHéritéDeObject ObjectHéritéDeObject::operator = ( ObjectHéritéDeObject const& other ) {   Object::Object ( ??! ) ; ...   _varriable = other._varriable ; _varriablePtr = new VarriablePtr( *( other._varriablePtr ) ) ;   etc...     return *this ;   }

---

ou il faut du coup recopier chaque variable pour la copie ?

Merci si vous pouvez m'aider

Je suis à peu près sûr que dans une construction par copie, le constructeur par copie de la classe mère est automatiquement appelé.
Dans tous les cas, le mieux reste d'utiliser la liste d'initialisation.
Ou réutiliser l'opérateur =

Citation:

---

Envoyé par Bousk

Je suis à peu près sûr que dans une construction par copie, le constructeur par copie de la classe mère est automatiquement appelé.

---

Non, il doit être appelé explicitement.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

public class MaBaseClass { protected: int Numero ; int Indice; public: MaBaseClass() { this->Numero = 0; this->Indice = 0; };   MaBaseClass(MaBaseClass & source) { this->Numero = source.Numero; this->Indice = source.Indice; }   virtual void Clone(MaBaseClass *target) { target->Indice = this->Indice; target->Numero = this->Numero; } };   public class MaSuperClasse : MaBaseClass { protected: int Compte; public: MaSuperClasse() : MaBaseClass(){ this->Compte = 0; }; MaSuperClasse(MaSuperClasse & source) : MaBaseClass(source) { this->Compte = source.Compte; }   virtual void Clone(MaSuperClasse *target) { MaBaseClass::Clone(target); target->Compte = this->Compte; } };

---

En effet, merci !

Qu'en est-t-il de l'operator ?
Doit-on recopier toutes les variables ?

Hum... Je sens qu'il y a quelques bases à reprendre.

L'affectation n'est pas compatible (sémantiquement, comme syntaxiquement) avec des hiérarchies. C'est l'un ou l'autre.
En fait, la copie, c'est souvent incompatible avec des hiérarchies. Parfois il arrive que l'on ait vraiment besoin de dupliquer, c'est là que clone() arrive. Mais ... d'abord on voit à concevoir sans cloner(), et si vraiment le besoin apparait, clone() arrivera. Mais seulement à ce moment là. On ne l'introduit pas en avance de phase juste "parce que on ne sait jamais".

A demander comment on fait pour l'affectation plus la question technique sur comment on écrit un constructeur de copie hérité, je soupçonne que tu es en fait dans cette approche : "au cas où on ne sait jamais". La bonne approche "on ne sait jamais" consiste à dire : "on interdit la copie par défaut, et on verra éventuellement plus tard".

correction...ca ne marche pas !

Quand je me contente d'expliciter:

Code:

---

1 2 3 4 5 6

ObjectFille::ObjectFille ( ObjectFille const& other ) : ObjectMere ( other ) { _NouvelleVariable = other._NouvelleVariable ; }

---

Il ne me copie pas l'objet (ou du moins aucune varriables) . Alors que si je recopie toutes les variables de l'ObjetMere, ca marche...

Enfin j'ai l'impression qu'il y a des objets ou ca marche, et d'autres pas...

Citation:

---

Envoyé par Luc Hermitte

L'affectation n'est pas compatible (sémantiquement, comme syntaxiquement) avec des hiérarchies. C'est l'un ou l'autre.

---

Entièrement d'accord. Espérons que oodini ne passe pas par là pour nous tenter de nous démontrer le contraire :mrgreen:

Citation:

---

Enfin j'ai l'impression qu'il y a des objets ou ca marche, et d'autres pas...

---

On peut pas t'aider sur des faits imprécis. Je soupçonne que tu as plusieurs niveaux de hiérarchies et que tu as commis une erreur en appelant explicitement le constructeur d'une classe qui n'est pas le parent direct de celle qui pose un problème.

Citation:

---

Envoyé par jblecanard

Je soupçonne que tu as plusieurs niveaux de hiérarchies et que tu as commis une erreur en appelant explicitement le constructeur d'une classe qui n'est pas le parent direct de celle qui pose un problème.

---

Effectivement, c'est une petite erreur souvent faite (surtout en C++, les formations utilisant trop les Java, C# qui font perdent beaucoup de sens) , dans le feu de l'action, on oublie quelques principes de bases concernant la durée de vie des objets à savoir :

- avoir un constructeur copie explicite pour chaque classe genre : MaClasse::MaClasse(const MaClass & source) qui appelle, dans l'ordre le ou les constructeurs copies des classes de base.
- avoir un constructeur vide (cTor par défaut) avec la visibilité qui va bien ( généralement protected - public )
- un destructeur qui gère l afin de vie.

Ces petites règles d’hygiène de base permettent de gérer à peu près correctement la vie des objets et de contourner le système de gestion automatique (copie superficielle d'objet par exemple) qui amène des bugs parfois inextricables.

Comme tu le dis Pascal, on perd vite certains fondamentaux suivant notre parcours. Mais allons encore plus loin : on a rarement besoin de la copie, en particulier quand nous sommes en présence d'entité, et une hiérarchie polymorphe est un signe fort de sémantique d'entité. La Forme Canonique Orthodoxe de Coplien que tu évoques s'applique aux classes à sémantique de valeur. Cf la FAQ.

Citation:

---

Envoyé par Luc Hermitte

Comme tu le dis Pascal, on perd vite certains fondamentaux suivant notre parcours. Mais allons encore plus loin : on a rarement besoin de la copie, en particulier quand nous sommes en présence d'entité, et une hiérarchie polymorphe est un signe fort de sémantique d'entité. La Forme Canonique Orthodoxe de Coplien que tu évoques s'applique aux classes à sémantique de valeur. Cf la FAQ.

---

Sourire, je pense que si mazertys17 consulte le fil de discussion, il va finir par prendre peur !! :)

Ceci dit, je suis tout à fait d'accord avec toi sur la différence de traitement infligeable à telle ou telle classe en fonction de sa destination; cependant, autant le clonage me semble à utiliser avec précaution uniquement quand la nécessité existe, autant le constructeur copie s'avère à implémentation plus systématique (le compilateur lui même en fabriquant un de toutes pièces si nécessaire et ma confiance dans les automatismes étant plus que relative).

Merci beaucoup pour toutes vos réponses, qui m'apprennent toujours un peut plus ! :)


Je crois bien que ce dont j'ai besoin est une forme canonique de Coplien...C'est a dire, si j'ai bien compris, une sorte d'objet model, qui sert a créer des objets basé sur ses caractéristiques.

Je crée un jeu vidéo, et j'ai besoin d'un gestionnaire de ressources : le but étant de charger un élément de décor, par ex, qui peut être multiplié autant de fois que demandé, avec les même caractéristiques que l'objet model ( par exemple une adresse de texture ) . les coordonnées sont ensuite transmises par le fichier du niveau qui va dire, par ex:

"elementDeDecorSol1 128x 256y ",
"elementDeDecorSol1 256x 512y ", etc...

Pour aller plus loin, j'ai besoin de pratiquer l'héritage, afin de pouvoir aller plus vite dans la programmation et d'avoir un code lisible, et qu'il soit facil d'implémenter de nouveaux éléments de jeu.

Pour l'instant, je crois m'en sortir pas trop mal, puisque tout fonctionne ( a l'état "embryonnaire" du programme ).

Pour la copie, je fais donc appel a une fonction clone, comme dit Luc Hermitte, qui fonctionne comme suit :

Code:

---

1 2 3 4 5 6

std::shared_ptr < Object > Object_HUD_Menu::clone() const { return std::shared_ptr < Object > ( new Object_HUD_Menu ( *this ) ) ; }

---

Mais j'ai pu constater que, si le constructeur de copie et l’opérateur d'affectation ne copient pas toutes les variables/objets nécessaire a la bonne gestion de l'objet, cela fonctionnait mal. C'est pourquoi j'ai du mal a comprendre ceci :

Citation:

---

L'affectation n'est pas compatible (sémantiquement, comme syntaxiquement) avec des hiérarchies. C'est l'un ou l'autre.

---

car si je n'utilise pas l'affectation ( si du moins il s'agit bien de l'opérateur / constructeur de copie ) , le clone se fait mal/pas..

Citation:

---

C'est l'un ou l'autre.

---

On ne pourrait donc pas pratiquer l'héritage et la copie impunément ( en terme de programme, hein :aie: ) ?

Hello

C'est un problème de sémantique avant tout. Mettons que tu possèdes une classe parente Resource dont héritent Texture et Son. Que veux-dire le code suivant ?

Code:

---

1 2 3 4 5 6

Texture t1; Son s1;   Resource& r1 = t1; Resource& r2 = s1; r2 = r1; // ??? problèmes en vue

---

Rien du tout, ça n'a aucun sens d'affecter un chou à une carotte. C'est pourtant ce qu'autorise l'implémentation de l'affectation sur une hiérarchie de classes. S'il est possible de le réaliser quand même en choisissant un sens quelconque, cela sera source d'erreurs difficiles à débugger plus tard, et n'apporte rien fonctionnellement.

A la description de ton besoin, il se peut qu'un membre clone() soit justifié, en revanche, je pense que tu dois interdire l'accès public à la création par copie et interdire l'affectation complètement. Ainsi, toute copie sera explicite via clone(). Maintenant que tu nous as mieux décrit ton besoin, tu as l'air de rechercher le pattern poids-mouche.

Citation:

---

Envoyé par jblecanard

Maintenant que tu nous as mieux décrit ton besoin, tu as l'air de rechercher le pattern poids-mouche.

---

THE truc par régis : http://rpouiller.developpez.com/tuto...-gang-of-four/ ;)

Merci pour vos réponses, et pour les infos sur les patterns...Je vais potasser tout ca.

Citation:

---

je pense que tu dois interdire l'accès public à la création par copie et interdire l'affectation complètement

---

Je vais suivre ce conseil ;)

Comment peut-on faire ce genre de choses ( si c'est pas trop demandé :oops: ) ?

Citation:

---

Envoyé par mazertys17

Comment peut-on faire ce genre de choses ( si c'est pas trop demandé :oops: ) ?

---

Très simple:

Code:

---

1 2 3 4 5 6 7 8

class Objet { public: // Autres contructeurs et membres publics Object& operator=(Object const&) = delete; // version C++11, mettre en private pour C++03   protected: Objet(Object const&); // En protégé, seules les classes enfant peuvent l'utiliser };

---

Ok, merci :D

Je ferais comme ça dorénavant !

par contre, comment çà peut se passer lors de la copie ? si je ne met pas d'objet référence "other" ?
D'autant plus que j'ai dans l'objet a copier, d'autres objets en pointeur qu'il faut allouer dynamiquement, et doivent eux aussi se copier depuis leurs modèles contenus dans l'objet référence.

En fait, j'ai l'impression de me retrouver dans un paradoxe...

Peut on, par exemple, faire un clone sans avoir besoin d’opérateur, ou de constructeur de copie ?

Car mon objet "dérivable" est censé servir a créer nombreuses autres class dérivés avec des fonctions très différentes, et donc, j'ai besoin de créer des fonctions virtuelles pures, pour éviter de rendre plus lourd mon programme (si je dis pas de bêtises ) et de simplifier mon code.

or, si j'ai bien compris, il est impossible d'instancier une class si la class mère a une fonction Virtuelle pure...?

Donc, je suis un peu coincé, vu que j'ai besoin, d'une part , de cloner des objets ( jeu vidéo oblige ) , et d'autre part, d'avoir une multitude de ces objets bâtis tout de même sur le même model ( avec graphics, son etc... ).

M'élancer dans le programme sans utiliser le concept des virtual pure, me conduirait bien vite a une pullulation de fonctions inutiles...

Et si je me trompe pas, quand on crée une fonction dans une class hérité, on est obligé de la déclarer au moins en virtual pure dans sa class mère ?


Merci si vous pouvez m'éclairer sur toutes ces interrogations.

Citation:

---

Envoyé par mazertys17

En fait, j'ai l'impression de me retrouver dans un paradoxe...Peut on, par exemple, faire un clone sans avoir besoin d’opérateur, ou de constructeur de copie ?Car mon objet "dérivable" est censé servir a créer nombreuses autres class dérivés avec des fonctions très différentes, et donc, j'ai besoin de créer des fonctions virtuelles pures, pour éviter de rendre plus lourd mon programme (si je dis pas de bêtises ) et de simplifier mon code. or, si j'ai bien compris, il est impossible d'instancier une class si la class mère a une fonction Virtuelle pure...? Donc, je suis un peu coincé, vu que j'ai besoin, d'une part , de cloner des objets ( jeu vidéo oblige ) , et d'autre part, d'avoir une multitude de ces objets bâtis tout de même sur le même model ( avec graphics, son etc... ). M'élancer dans le programme sans utiliser le concept des virtual pure, me conduirait bien vite a une pullulation de fonctions inutiles... Et si je me trompe pas, quand on crée une fonction dans une class hérité, on est obligé de la déclarer au moins en virtual pure dans sa class mère ?

---

Ce problème vient du fait que l'approche par héritage, pour coder un game engine, n'est pas la bonne ! Tu devrais imaginer une architecture basée sur de l'aggrégation de pas de l'héritage. Tu devrais sérieusement considérer l'usage d'un entity system. Celui-ci est assez simple et peut répondre à tes besoins. En tout cas passe du temps à te documenter sur le sujet. Cet article raconte comment l'héritage peut devenir un enfer pour le gamedev, et celui-ci résume assez bien le concept. Internet regorge d'autres ressources sur le sujet.

Citation:

---

Ce problème vient du fait que l'approche par héritage, pour coder un game engine, n'est pas la bonne !

---

:aie:

Vous avez plus d'expérience que moi, c'est certain, alors je vais vous écouter, et bien réfléchir , quitte a faire un ( xème ) nouveau départ. :mouarf: , cependant j'aimerais au moins défendre ma thèse pour voir ce que vous en pensez ;)

En fait j'avais déjà réalisé mon jeu sur 4 niveaux jouables (ou plus, avec editeur de niveau ), comprenant des éléments de bases ( mais assez complexe tout de même ) , qui fonctionnent. Je m'étais justement dit a la base que l'héritage n'était pas adapté, alors chaque objet avait sa propre classe.
Mais quand est arrivé le moment ou nombre d'autres objets étaient à créer, je me suis dit que finalement, l'héritage, ça pouvait être pratique.

Dans mon nouveau programme, je conte/ais utiliser un object de base "Object" qui serait la class mère de tous les objets du jeux ( enfin du moins tous les objets affichables ). dans le but d'avoir une ENGINE qui ait simplement un/des " std::vector <Object> ", ou , dans mon cas, un objet " OBJECT_Container " qui contient des vector <Object >, ce qui revient au même.
Tout ça dans le but de pouvoir englober tous les objets :

Je me dis qu'en procédant ainsi, je n'ai plus besoin de toucher à mon moteur, qui comprend un système de light, collision, gestion des ressources etc... : il compare tous les objets de la même facon, puisqu'ils sont tous hérités de Object.

et si j'ai un objet qui doit avoir l'adresse d'autres objets, par ex , pour interragir en fonction, je peux/pourrais avoir :

Code:

---

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

class Object_Interactif_Mobile_QuiFaitQuelqueChoseDeTresParticuler : public Object_Interactif_Mobile { public: //...   protected :   std::vector < std::shared_ptr < Object > > _chaineDObjectAuQuelIlPuisseAvoirAccesPourFairePleinDeChoses ;   }

---

Je n'y suis pas encore, mais du moins, l'objectif est/était là.

Et pour créer les objets, je fais appel a un système de lecture sur le disque dure. Des feuilles sont préparés avec toutes les carractéristiques des objets ( textures, tailles couleur etc.. ). J'ai ainsi juste le nom de l'objet a rajouter dans un vector, contenue dans un objet RESOURCES, et si le niveau y fait appel, alors , celui ci est crée en lisant sur le disque dur.

La seule chose un peu lourde est dans l'organisation de la lecture du fichier...c'est sur : si le nom de l'objet demandé, par exemple, est " Object_HUD_Menu" , il va devoir créer l'objet "std::vector < Object_HUD_Menu > object ;" à partir de Object...

Pour l'instant, ca marche. ( mais je ne sais pas ce que me réserve la suite...).

Mais maintenant que vous me dites que c'est pas adapter...je vais lire et potasser pour voir ce qui est le meilleur pour mon niveau . ( merci pour les liens )

Merci donc, si vous pouvez me dire ce que vous en pensez, et relever les failles qui vous apparaissent !

Apparemment, tu as quand même déjà pas mal codé sur ton jeu. Tu n'es pas obligé de tout casser d'un coup, tu peux faire migrer ton code vers une meilleure version progressivement. Il ne faut pas prendre les choses par l'extrême : si je dis que l'héritage est une mauvaise approche, j'entend par là l'usage d'une hiérarchie de classe à plusieurs niveaux pour modéliser les entités. Ca ne veut pas dire qu'il ne faut pas du tout s'en servir :). Si tu regardes un peu l'entity system que je t'ai montré, de l'héritage est utilisé. Mais pas pour composer les comportements des différentes entités.

Autre chose : si tu veux mener ton projet à bien, concentre toi sur le jeu et pas sur le moteur. Je veux dire par là : ne code dans ton moteur que les features que ton jeu requiert. C'est une erreur courante de vouloir faire un super moteur qui finalement fait tout à la fois mais rien correctement. Le moteur est au service du jeu et pas l'inverse. Je ne sais pas où tu en es par rapport à ça, mais c'est un conseil qui ressort régulièrement.

Je n'ai pas bien compris ton histoire de chargement de fichiers, peut-être que le sujet devrait être traité dans un autre post ?

Ok, merci !

Je vais suivre vos conseils et lire les documentations. Le système d'agrégation a l'air en effet plus adapté : je risque de faire un programme peu robuste si je base tout sur l'héritage..

Merci pour votre suivit ! :)