Discussion :

[mazertys17]

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 :

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

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 :

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

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

[jblecanard]

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 :

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

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.

[pascalCH]

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/

[mazertys17]

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

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é ) ?

[jblecanard]

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

Très simple:

Code :

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

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
};

[mazertys17]

Ok, merci

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.

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


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

[jblecanard]

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.

[mazertys17]

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

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

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

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 !

[jblecanard]

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 ?

[mazertys17]

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 !