Discussion :

[LittleWhite]

Bonjour,

Je suis sur un nouveau programme OpenGL. À la base, tout objets OpenGL est identifiable avec un GLuint. Pour chaque type d'objet OpenGL, nous avons une fonction associée, créant l'objet du coté de la bibliothèque et nous retournant l'identifiant.

Je cherche en quelque sorte à encapsuler ce design.

Au début, je pensais faire un objet GLObject parent de tous, de la façon suivante :

Code c :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#ifndef GLOBJECT_HPP
#define GLOBJECT_HPP
 
#include <GL/glew.h>
 
class GLObject
{
    protected:
 
        GLuint m_glID;
 
        virtual void create()=0;
        virtual void destroy()=0;
 
    protected:
 
        GLObject():m_glID(0) { create(); }
        virtual ~GLObject() { destroy(); }
};
 
#endif

Comme cela, une classe Texture hérite de GLObject et doit réimplémenté les fonctions create() et destroy() en appelant les fonctions OpenGL appropriées.

Mais, le compilateur a voulu s'en mêler et m'a signalé que je faisais surement un truc de mal avec mes appels à des fonctions pure dans le constructeur / destructeur.
Du coup, j'imagine que j'ai un problème de design.

Pourquoi ne pas vouloir faire l'appel des fonctions OpenGL dans les constructeurs / destructeurs, à vrai dire je ne suis pas trop sur. Principalement, car je souhaitais avoir une fonction séparée pour la gestion de OpenGL (séparée de la construction de l'objet). Enfin bref, cela est surement idiot, surtout que je l'appel dans le constructeur afin d'être bien sur qu'elle soit appelée.

Par contre, je me demande comment vous feriez ?
L'avantage d'avoir une classe GLObject, c'est que je pourrai avoir une banque d'objet qui pourrait même indiquer l'utilisation faite des objects OpenGL et permettre leurs destruction automatiquement.

[Invité]

Bonsoir,
Personnellement j'ai du mal a voir l’intérêt de tels fonctions... Après tout la classe Texture possède elle aussi un constructeur et un destructeur : pourquoi ne pas appeler les fonctions OpenGl dedans ? Et puis ça me parait bizarre que la classe de base s'occupe de dire aux classes filles qu'elle doivent s'initialiser alors que sa propre initialisation n'est pas terminée (puisqu'on est pas sorti de son constructeur)

[koala01]

Salut,

Il ne faut pas oublier que, dans le constructeur et dans le destructeur, on ne connait que le type de l'objet que l'on est occupé à (créer ou à détruire , évidemment) et de ses parents...

ou, plutot, dans l'autre sens : on ne connait rien, dans le constructeur ou dans le destructeur d'une classe, des classes qui peuvent éventuellement dériver de celle sur laquelle on travaille

Cela implique que, si tu fais appel à une fonction virtuelle dans le constructeur (ou dans le destructeur) de la classe de base, c'est la version de la classe de base de la fonction qui sera appelée, et non une quelconque redéfinition de celle-ci

Or, si ta fonction est virtuelle, c'est parce que tu t'attends à ce qu'elle réagisse correctement pour le type dérivé dans lequel elle est redéfinie

Le compilateur a donc deux fois raison de refuser de tels appels :

1. Parce que, au niveau de la classe de base, il s'agit de fonctions virtuelles pures, ce qui signifie "sans contenu"
2. parce que, si tu fournissait un comportement à ces fonctions pour le type de base, ce serait ce comportement précis qui serait utilisé, et non le comportement particulier du type dérivé, et auquel tu t'attends sans doute

A bon entendeur

[Xtrem_Voyageur]

Salut LittleWhite!
Ca fait longtemps que je ne suis pas venu sur le t'chat

J'ai lu en diagonale mais comme l'a dit Koala, n'appelle jamais de fonctions virtuelles dans les constructeurs et destructeurs.
Maintenant, je ne suis pas sûr d'avoir saisi ce que tu veux réellement faire mais un design pattern pourrait peut-être t'aider, Abstract Factory / Factory Methods.

Si tu peux développer, en donnant une hiérarchie de classes et l'utilisation que tu en ferais, cela sera plus aisé de t'apporter une réponse appropriée.

[LittleWhite]

Il est plus qu'évident que mon design était pourri et irréfléchi.
Pour la Factory, je pense que cela sera pratique surtout si je veux faire un suivi des objets crée.
Du coup, je vais partir sur un objet GLObject qui ne contiendra qu'un GLint et qui sera hérité.

Merci pour vos réponses

[koala01]

Il est plus qu'évident que mon design était pourri et irréfléchi.
Pour la Factory, je pense que cela sera pratique surtout si je veux faire un suivi des objets crée.
Du coup, je vais partir sur un objet GLObject qui ne contiendra qu'un GLint et qui sera hérité.

Merci pour vos réponses

Oui, mais... hummm!!!...

Je ne dis pas que ce n'est pas la solution, mais, ma grosse crainte, c'est que tu finisse, à cause de ce "god object", par faire cohabiter des poires avec des voitures au seul prétexte qu'elles ont toutes les deux un numéro et une couleur

si tu crées ton "GlObject", quelle en sera la responsabilité

Cette responsabilité sera-t-elle compatible avec les responsabilité des classes qui en héritent

Ne peut on pas envisager de dire que le fait de fournir un moyen permettant d'obtenir un identifiant (unique) telle qu'une fonction id() n'est qu'un prérequis d'interface commun à tout objet qui sera manipulé, sans pour autant que cela ne nécessite une hiérarchie unique et monolithique

Mieux encore, ne peut on pas envisager le fait que tout ce qui a traiit à OpenGL n'a strictement rien à voir avec la hiérarchie d'objet que tu t'apprêtes à créer, dans le sens où tes objets n'ont, a priori, aucune raison d'avoir la responsabilité de leur affichage

Je n'ai pas de réponse toute faite à ces questions (ce qui ne m'empêche pas d'avoir mon avis ), ne sachant pas exactement quels sont tes objectifs, et je me contente d'énumérer certains écueils qu'il me semble difficile d'éviter en partant sur le principe que tu envisages d'utiliser

Peut etre serait-il utile que tu réfléchisse à la réponse à donner à chacune de ces questions, ne serait-ce que pour t'assurer que tu auras pris la bonne décision en pleine connaissance de cause