Design multi-api et traitement différé

Bonjour à tous,

Ce post fais suite à celui-ci : http://www.developpez.net/forums/d12...programmation/.

Je viens demander votre aide pour résoudre un problème de design. En effet, pour la suite j'ai besoin de partir sur de bases saines, afin par la suite de ne pas à avoir à recommencer une n-ième fois..

Voici l'ensemble du problème résumé ci-dessous :
- La bibliothèque va être un moteur de rendus multi-api (typiquement opengl et directx, mais pourquoi pas opengl es, software, etc).
- Si besoin le choix de l'api peut se faire à la compilation, grâce aux templates, préprocesseur ou tout autre manière. Mais cela n'est pas une obligation et dépendra du design général.
- boost et c++11 sont fortement conseillés :aie:
- Le moteur doit être facilement extensible.
- Éviter les pointeurs nus au maximum!

Voici le schéma général : une ressource CPU devient une ressource GPU, et un renderer applique tout un tas de traitements dessus. En effet, le traitement différé (dans un renderer) est obligatoire pour des raisons liés aux APIs.

Par exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10

class shader_base { shader_base(const std::string &src); };   class ogl_shader {}; class dx_shader {};   // Le shader (ressource GPU), est crée à partir d'un code source (ressource GPU). // Il sera ensuite binder par le bon renderer.

---

Maintenant je cherche à trouver un bon design pour tout cela. J'ai donc trouver plusieurs pistes, chacune possédant plusieurs avantages et inconvénients.
Je vais les exposer ci-dessous. J'espère que vous pourrais me donner une direction, ou même une voie perpendiculaire à tout ça :aie:

• Visiteur
  Je suis tout d'abord partis sur le design pattern du visiteur, surtout inspiré par l'article d'Emmanuel Deloget. Malheureusement, il en ressort que c'est peut-être pas le plus adapté dans le choix où l'api serait choisit à la compilation : en effet dans un pareil cas, il perd son intérêt non?
  Mais surtout qu'il crée des dépendances entre les classes, et complique l'ajout de fonctionnalités.
  
  
• Template
  Pour cela j'ai pensé créer une classe template renderer, spécialisé suivant les APIs par des classes "tags".
  
  
  Code:

  ---

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

  template<typename T> class renderer;   struct ogl {}; // tag opengl   template<> class renderer<ogl> { typename ogl_shader shader_type; typename ogl_texture texture_type;   // ainsi de suite };

  ---

  Cette fois-ci le problème c'est que certaines classes dépendaient de l'api alors que ça ne devait pas être le cas : imaginons une classe material constitué de shaders. Comment je déclare les shaders dans ma classe material, sans faire renderer<ogl>::shader_type?
  Et cela pose problème car cette classe doit être indépendante de l'api.
  
  
• Préprocesseur
  Dans les choix de l'API à la compilation j'ai opté pour la solution suivante à base de préprocesseur:
  
  Code:

  ---

  1 2 3 4 5 6 7 8 9 10

  #if defined USE_OPENGL typename ogl_shader shader_type; typename ogl_texture texture_type;   // ainsi de suite   #elif defined USE_DIRECTX // rebelote   #endif

  ---

  Et ce fichier serait inclus partout où l'on se sert des objets liés aux APIs. Néanmoins cela oblige donc tout le monde à avoir accès à plus que l'interface de base par exemple..
  
  Et puis j'aime bien les templates :aie:
  
  
• Interface abstraite
  Cette fois-ci c'est un renderer abstrait comme suivant (basé sur un article de Laurent Gomilla http://loulou.developpez.com/tutorie.../partie8/#L4.3):
  
  Code:

  ---

  1 2 3 4 5 6 7 8

  class renderer_base { virtual std::shared_ptr<shader_base> createShader(/*...*/) = 0;   virtual void bind(const std::shared_ptr<shader_base> &s) = 0;   // ... };

  ---

  Seulement cela oblige dans les classes filles à downgrader les classes reçus en paramètres de la façon suivante:
  
  
  Code:

  ---

  1 2 3 4 5 6 7 8 9 10

  class renderer_ogl { virtual void bind(const std::shared_ptr<shader_base> &s) { auto shader = std::static_pointer_cast<shader_ogl>(s);   // suite du code ... } };

  ---

  Cela m'embête un peu de downgrader comme ça, au tant du point de vue design que performance.
  

Donc j'espère bien que quelqu'un pourra m'éclairer et que mon post n'est pas trop long :ccool: Quitte à proposer une autre solution à base de traits ou autre!

Merci d'avance!

:salut:
On avait fait une review du code de LittleWhite sur son projet OpenAWars, qui lui avait permit de concevoir une API indépendante du système graphique (il utilisé la SDL par exemple et j'ai pu faire une version Qt en 5 min) : http://www.developpez.net/forums/d96...nce-wars-like/
C'est un peu long à lire, mais on aborde pas mal de questions sur le design

Bonjour,

Je ne comprends pas trop ton problème avec les templates, si ta classe material est constitué de shader et que les shader dépendent de l'api, alors la classe material en dépend aussi. Comment pourrait-il en être autrement ?

Ce besoin d'indépendance de certaines classes vient de quoi ? Tu as certaines fonctions qui viennent d'une api extérieur que tu vas devoir utiliser ? Dans ce cas tu n'as pas la possibilité de transmettre les fonctions directement aux classes qui les utiliseront comme elles veulent ?

@gbdivers : Beaucoup de point son intéréssant comme les posts de Emmanuel Deloget en page 8. Merci je vais approfondir tout cela!

@Flob90 : C'est la peur du code redondant je pense surtout.

Alors dans ce cas là je vais me retrouver avec une classe material template de la sorte?

Code:

---

1 2 3 4 5 6 7 8 9 10 11

template<typename api> class material { std::shared_ptr<renderer<api>::shader_type> m_shader;   // exemple : setter void shader(const std::shared_ptr<renderer<api>::shader_type> &s) { m_shader = s; } };

---

De même pour les mesh (contenant les buffers hardwares du mesh en lui-même)? Et chacune des classes qui vont manipuler material ou mesh vont donc avoir un paramètre template représentant l'api?

Cela ne deviendrait-il pas trop intrusif?

Je ne trouve pas ça vraiment intrusif, c'est générique : un seul code (de material) pour toutes les api, il n'y a pas de redondance.

Par contre, si il n'y a qu'un renderer dans ta classe material (et que rien d'autre ne dépend de l'api), alors il ne serais pas envisageable de le mettre comme paramètre template des fonctions en ayant besoin ? (Sauf si toute les fonctions en ont besoin).

Je n'y connais rien en API graphique, mais ça aurait un sens d'écrire quelque chose comme ?

Code:

---

1 2 3

renderer << material1 << material2 << other; //Ou un autre opérateur binaire

---

Dans ce cas ta classe material n'a pas besoin d'être template, et tu pourrais définir des fonctions template libres amies de material qui fait ce qu'il faut.

Pour faire rapide, OpenGL travaille avec un ensemble d'objet en interne tels que des program (ensemble de shaders), framebuffers, etc.

Chacun de ces objets réside en mémoire graphique, sur le GPU. L'API met a la création de chacun un identifiant unique à transmettre lors de l'appel des fonctions :

Code:

---

1 2 3 4 5 6

GLuint handle = glCreateProgram();   // ...   glUseProgram(handle);

---

Mais sourtout, OpenGL ne peut avoir d'activer qu'une seule et unique instance pour chacun de ces types! Donc un seul program, une seule texture, etc sont active à un instant t.
De plus si je centralise tout le traitement dans une classe renderer, c'est dû aux extensions OpenGL et certaines spécificités utilisé par la suite!



Pour revenir encore sur la généricité, étant donnée que je dois avoir accès aux spécialisations de la classe renderer pour faire par exemple:

Code:

---

renderer<ogl>::shader_type

---

Cela veut donc dire que dans mes classes (material par exemple) je dois inclure chacune des spécialisations des renderers?

Merci encore!

Les spécialisations templates doivent être définient après la déclaration (voir la définition selon les cas) du template, et avant la première utilisation de la spécialisation qui "force" une instanciation template.

Dans ton cas, si renderer est un template, elle ne forcera rien à être instancier tant que tu ne l'instancie pas elle même. Or au moment où ceci arrivera tu auras nécessairement les spécialisations pour tes "tag" :

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

//h1.hpp template<class T> struct renderer;   //h2.hpp #include "h1.hpp"   template<class T> struct material { typedef typename renderer<T>::shader_type shader_type; };   //h3.hpp #include "h1.hpp"   struct ogl;   template<> struct renderer<ogl> { typedef /*...*/ shader_type; };     //tu.cpp   #include "h3.hpp" #include "h2.hpp"   //... renderer<ogl> r; material<ogl> m(r);

---

Quelque chose dans ce goût la ne devrait pas poser de problème, au moment de l'instanciation des template (dans tu.cpp), l'ensemble des templates et des spécialisations utilisées est connue.

Si tu centralises, pour reprendre ce que tu disais, et que cette élément centrale dépend de l'api, alors tu as deux approches :

• C'est la classe qui centralise qui s'occupe de tout faire, et dans ce cas tu peux réaliser des éléments de design indépendant de l'api que l'élément centrale utilisera comme il veut.
• C'est la classe qui centralise qui permet à divers éléments de tout faire, mais dans ce cas les autres éléments du design vont forcément dépendre indirectement de l'api.

Personnelement je serais très prudent avec une approche centralisée, on tombe facilement dans des solutions de facilités qui viennent pourrir toute évolution future du design.

La première solution a un défaut assez important c'est que c'est un design qui se dirige clairement vers un god object : ca va marcher mais c'est pas l'idéal pour des évolutions futures.

La seconde, bien que tu sembles penser que c'est génant, ne pose pas de réels problèmes, ca va te faire des élèments écrient en fonction d'un paramètre template, c'est si génant que ca ?

• Il n'y aura aucune redondance du code, le paramètre template sera là pour permettre l'utilisation du bon type de renderer, mais tes interfaces renderer devraient offrir une partie de l'interface commune (dont l'implémentation pourra varier) que les classes pourront utiliser.
• La conservation du tag "quelque part" pourra permettre l'optimisation de certaines fonctions n'importe où dans le design en utilisant des méthodes de tag dispatching (directement sur le tag de l'api ou sur des tag "caractéristiques"). (*)
• La partie génante est de devoir repréciser l'api à chaque élément. Ce défaut se contourne de manière partiel en utilisant des fonctions de création (make_pair par exemple) et totalement si tu les couples à auto (C++11).

NB: Les deux solutions ont un risque d'introduire une dépendance forte de tout le design à l'interface de renderer.

(*) A la manière des algorithmes sur les itérateurs pour les différentes catégories d'itérateurs. Tu peux faire la même chose si tu arrives à créer des catégories pour les différentes caractéristiques de tes api (je ne connais rien à opengl et dx, ca ne s'applique donc peut-être pas).

Citation:

---

Envoyé par victor_gasgas

La bibliothèque va être un moteur de rendus multi-api (typiquement opengl et directx, mais pourquoi pas opengl es, software, etc).

---

Moteur de rendus (ie qui fournit des services telle "dessiner un cube", "dessiner un mesh", "appliquer une texture") ou une abstraction commune pour les api 3d (id fournit les services "créer un programme", "créer un shader", "transférer un buffer sur le gpu") ?
D'après ce que je vois ensuite, ça m'a l'air d'être la seconde possibilité (je reviendrais ensuite sur le pourquoi la distinction me semble importante)

Citation:

---

Envoyé par victor_gasgas

En effet, le traitement différé (dans un renderer) est obligatoire pour des raisons liés aux APIs.

---

Détails d'implémentation internes, qui ne doivent pas entrer dans l'api de ton moteur.
En règle générale, j'ai l'impression que tu ne ne fais pas la différence dans ton design ce qui fait partie de l'api (ie les services rendus) et les détails internes

Citation:

---

Envoyé par victor_gasgas

Cette fois-ci le problème c'est que certaines classes dépendaient de l'api alors que ça ne devait pas être le cas : imaginons une classe material constitué de shaders. Comment je déclare les shaders dans ma classe material, sans faire renderer<ogl>::shader_type?
Et cela pose problème car cette classe doit être indépendante de l'api.

---

Tu peux tout à fait avoir un concept material indépendant de l'api 3D et avoir un concept apply_material qui en dépend

Citation:

---

Envoyé par Flob90

Je ne comprends pas trop ton problème avec les templates, si ta classe material est constitué de shader et que les shader dépendent de l'api, alors la classe material en dépend aussi. Comment pourrait-il en être autrement ?

---

En général, un material, c'est juste un ensemble d'informations (quel texture de couleur de couleur, de texture d'AO, la normal map, etc), donc indépendant du code des shaders (ou presque)

Citation:

---

Envoyé par Flob90

Je n'y connais rien en API graphique, mais ça aurait un sens d'écrire quelque chose comme ?

Code:

---

1 2	renderer << material1 << material2 << other; //Ou un autre opérateur binaire

---

Dans ce cas ta classe material n'a pas besoin d'être template, et tu pourrais définir des fonctions template libres amies de material qui fait ce qu'il faut.

---

Si ça se fait. Je crois que l'on a ça dans Qt3D

Code:

---

Mais sourtout, OpenGL ne peut avoir d'activer qu'une seule et unique instance pour chacun de ces types! Donc un seul program, une seule texture, etc sont active à un instant t.

---

C'est un détail d'implémentation interne. D'ailleurs, ce n'est pas obligatoire, tu peux travailler sans (direct mode), ou utiliser l'une des nombreuses possibilités (list, VAO, VBO, etc). Pour aller plus loin, je dirais que si tu veux un système évolutif, tu ne peux pas te baser sur un modèle en particulier, sinon tu risques de devoir changer lorsqu'il y a aura des évolutions (un nouveau type de BO par exemple)

Citation:

---

Envoyé par victor_gasgas

Cela veut donc dire que dans mes classes (material par exemple) je dois inclure chacune des spécialisations des renderers?

---

vaut mieux pas, sinon, tes material sont dépendant de l'api



Pour revenir sur le premier point.
Tu sembles vouloir faire une api qui permet de faire une abstraction des api 3D. Par exemple, si tu veut créer une shader en gl ou en d3d, tu devrais appeler les fonctions suivantes : CreateVertexShader ou glCreateShader. Pour ça, rien de compliqué, tu fais une simple fonction createShader qui appelle la fonction correcte selon l'api utilisée.
Le but est donc d'avoir du code indépendant de l'api 3d, mais d'appeler quand même des fonctions bas niveau (createShader, runKernel, etc)
Le problème est que tu devras écrire des shaders qui dépendront de l'api. C'est à dire que même si tu as une fonction createShader indépendante de l'api 3D, tu devras quand même faire du code (avec un #ifdef par exemple) qui dépendant de l'api 3D.
Donc en gros, tu n'as fait aucune abstraction et l'intérêt d'une telle api est très limitée :aie:

Ce qui est intéressant, c'est de faire une abstraction qui te permet de manipuler des concepts 3D ("dessiner un cube", "dessiner un mesh", "appliquer une texture") indépendant de l'api 3D. Donc sans donner un code de shader spécifique à l'api 3D

Je vais essayer de répondre à toute ces précieuses réponses!

Citation:

---

Envoyé par Flob90

Les spécialisations templates doivent être définient après la déclaration (voir la définition selon les cas) du template, et avant la première utilisation de la spécialisation qui "force" une instanciation template.

Dans ton cas, si renderer est un template, elle ne forcera rien à être instancier tant que tu ne l'instancie pas elle même. Or au moment où ceci arrivera tu auras nécessairement les spécialisations pour tes "tag" :

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

//h1.hpp template<class T> struct renderer;   //h2.hpp #include "h1.hpp"   template<class T> struct material { typedef typename renderer<T>::shader_type shader_type; };   //h3.hpp #include "h1.hpp"   struct ogl;   template<> struct renderer<ogl> { typedef /*...*/ shader_type; };     //tu.cpp   #include "h3.hpp" #include "h2.hpp"   //... renderer<ogl> r; material<ogl> m(r);

---

Quelque chose dans ce goût la ne devrait pas poser de problème, au moment de l'instanciation des template (dans tu.cpp), l'ensemble des templates et des spécialisations utilisées est connue.

---

Je ne pensais pas et cela va m'être très utile je pense du coup! Mais donc pour tout tu ferais passer l'instace du renderer à chaque fois? C'est vrai que je n'y avais pas pensé, mais cela peut sans doute beaucoup aider!

Citation:

---

Envoyé par Flob90

Si tu centralises, pour reprendre ce que tu disais, et que cette élément centrale dépend de l'api, alors tu as deux approches :

• C'est la classe qui centralise qui s'occupe de tout faire, et dans ce cas tu peux réaliser des éléments de design indépendant de l'api que l'élément centrale utilisera comme il veut.
• C'est la classe qui centralise qui permet à divers éléments de tout faire, mais dans ce cas les autres éléments du design vont forcément dépendre indirectement de l'api.

Personnelement je serais très prudent avec une approche centralisée, on tombe facilement dans des solutions de facilités qui viennent pourrir toute évolution future du design.

---

Je sais que centraliser va poser problème, mais dans ce contexte je sais pas du tout comment faire. Je m'explique : l'API OpenGL impose que ce soit le thread où a été crée le contexte qui envoie toutes les commandes.

Or dans un contexte multi-threadé je ne sais pas comment faire autrement. Une fifo peut-être mais il faudrait qu'elle soit connue de tous les objets..

Ensuite, sous Windows, je suis obligé de chargé toutes les fonctions OpenGL à la main, et donc j'ai tout mis dans la classe renderer là.

Citation:

---

Envoyé par Flob90

La première solution a un défaut assez important c'est que c'est un design qui se dirige clairement vers un god object : ca va marcher mais c'est pas l'idéal pour des évolutions futures.

La seconde, bien que tu sembles penser que c'est génant, ne pose pas de réels problèmes, ca va te faire des élèments écrient en fonction d'un paramètre template, c'est si génant que ca ?

• Il n'y aura aucune redondance du code, le paramètre template sera là pour permettre l'utilisation du bon type de renderer, mais tes interfaces renderer devraient offrir une partie de l'interface commune (dont l'implémentation pourra varier) que les classes pourront utiliser.
• La conservation du tag "quelque part" pourra permettre l'optimisation de certaines fonctions n'importe où dans le design en utilisant des méthodes de tag dispatching (directement sur le tag de l'api ou sur des tag "caractéristiques"). (*)
• La partie génante est de devoir repréciser l'api à chaque élément. Ce défaut se contourne de manière partiel en utilisant des fonctions de création (make_pair par exemple) et totalement si tu les couples à auto (C++11).

---

et donc ici ce serait un make_* pour chacun des objet + auto? Peux-tu me donner un petit exemple car je suis un peu perdu là.

Citation:

---

Envoyé par Flob90

NB: Les deux solutions ont un risque d'introduire une dépendance forte de tout le design à l'interface de renderer.

(*) A la manière des algorithmes sur les itérateurs pour les différentes catégories d'itérateurs. Tu peux faire la même chose si tu arrives à créer des catégories pour les différentes caractéristiques de tes api (je ne connais rien à opengl et dx, ca ne s'applique donc peut-être pas).

---

Citation:

---

Envoyé par gbdivers

Moteur de rendus (ie qui fournit des services telle "dessiner un cube", "dessiner un mesh", "appliquer une texture") ou une abstraction commune pour les api 3d (id fournit les services "créer un programme", "créer un shader", "transférer un buffer sur le gpu") ?
D'après ce que je vois ensuite, ça m'a l'air d'être la seconde possibilité (je reviendrais ensuite sur le pourquoi la distinction me semble importante)

---

Alors le moteur se positionne tout d'abord comme une abstraction des APIs, et par dessus je souhaiterais donner les possibilités étendus, comme un graph de scène, material, multi-passe, etc.

Citation:

---

Envoyé par gbdivers

Détails d'implémentation internes, qui ne doivent pas entrer dans l'api de ton moteur.
En règle générale, j'ai l'impression que tu ne ne fais pas la différence dans ton design ce qui fait partie de l'api (ie les services rendus) et les détails internes


Tu peux tout à fait avoir un concept material indépendant de l'api 3D et avoir un concept apply_material qui en dépend

---

Pourrais-tu developper cette partie là s'il te plait, car je pense bien qu'il faille scinder interface et implémentation le plus possible!

Citation:

---

Envoyé par gbdivers

En général, un material, c'est juste un ensemble d'informations (quel texture de couleur de couleur, de texture d'AO, la normal map, etc), donc indépendant du code des shaders (ou presque)


Si ça se fait. Je crois que l'on a ça dans Qt3D

Code:

---

Mais sourtout, OpenGL ne peut avoir d'activer qu'une seule et unique instance pour chacun de ces types! Donc un seul program, une seule texture, etc sont active à un instant t.

---

C'est un détail d'implémentation interne. D'ailleurs, ce n'est pas obligatoire, tu peux travailler sans (direct mode), ou utiliser l'une des nombreuses possibilités (list, VAO, VBO, etc). Pour aller plus loin, je dirais que si tu veux un système évolutif, tu ne peux pas te baser sur un modèle en particulier, sinon tu risques de devoir changer lorsqu'il y a aura des évolutions (un nouveau type de BO par exemple)

---

Tout à fait d'accord avec toi, mais même si le moteur sera multi-api, je compte faire du OpenGL 4 et directx 11 minimum. Mais cela n'est que dans le meilleur des mondes :mrgreen: Je n'aurais sûrement pas le temps de tous les faire, donc je pense tout d'abord me concentrer sur ogl.

Citation:

---

Envoyé par gbdivers

vaut mieux pas, sinon, tes material sont dépendant de l'api

---

Oui et cela rejoins donc les commentaires de Flob sur l’instanciation de templates.

Citation:

---

Envoyé par gbdivers

Pour revenir sur le premier point.
Tu sembles vouloir faire une api qui permet de faire une abstraction des api 3D. Par exemple, si tu veut créer une shader en gl ou en d3d, tu devrais appeler les fonctions suivantes : CreateVertexShader ou glCreateShader. Pour ça, rien de compliqué, tu fais une simple fonction createShader qui appelle la fonction correcte selon l'api utilisée.
Le but est donc d'avoir du code indépendant de l'api 3d, mais d'appeler quand même des fonctions bas niveau (createShader, runKernel, etc)
Le problème est que tu devras écrire des shaders qui dépendront de l'api. C'est à dire que même si tu as une fonction createShader indépendante de l'api 3D, tu devras quand même faire du code (avec un #ifdef par exemple) qui dépendant de l'api 3D.
Donc en gros, tu n'as fait aucune abstraction et l'intérêt d'une telle api est très limitée :aie:

Ce qui est intéressant, c'est de faire une abstraction qui te permet de manipuler des concepts 3D ("dessiner un cube", "dessiner un mesh", "appliquer une texture") indépendant de l'api 3D. Donc sans donner un code de shader spécifique à l'api 3D

---

C'est vrai que par exemple pour les shaders je pourrais utiliser CG, mais je préfère laisser le côté natif. Le but n'est pas de pouvoir changer d'un coup à l'autre d'API, mais de pouvoir en choisir une pour un programme selon des contraintes et de s'y tenir, le tout dans une interface unifiée.

Pour les fonctions de créations :

Code:

---

1 2 3 4 5 6 7 8

template<class tag> material<tag> make_material(renderer<tag>& r) { return material<tag>(r); }   //... renderer<ogl> r; auto m=make_material(r);

---

Après on peut faire autrement, prendre en paramètre template directement le type du renderer et utiliser un typedef ou un trait pour récupérer le tag par exemple.

Ensuite si tu t'autorise le C++11 avec les templates variadics, tu dois même pouvoir faire une seule fonction make pour toutes tes classes, y compris si elles ont besoin d'autre argument que le renderer à l'initialisation :

Code:

---

1 2 3 4 5 6 7 8

template<template<class> class T, class tag, class... Args> T<tag> make(renderer<tag>& r, Args...) { /*...*/ }   //... renderer<ogl> r; auto material=make<material>(r,/*...*/);

---

NB: C'est juste l'idée, à faire proprement avec std::forward.

Si tes classes n'ont pas de sémantique de copie, alors ça marche aussi avec une allocation dynamique, à toi de voir.

Ca c'est dans le cas où le renderer est nécessaire à l'ensemble de la classe material, si il ne sert que pour certaines fonction, alors je le laisserais en paramètre des fonctions qui en ont besoin.

Oui je m'autorise tout ce qui est supportée par gcc dans ça dernière version stable :mrgreen:
Il faut vraiment que je me renseigne sur std::forward. Cela permet de passer les arguments "variadics" des fonctions sans faire de copies?

Après il faut voir si en faisant passer un renderer à la création plus une touche d'amitié pour restreindre l'interface si j'arrive pas à avoir une interface qui commence à être pas mal.

Citation:

---

Envoyé par Flob90

Si tes classes n'ont pas de sémantique de copie, alors ça marche aussi avec une allocation dynamique, à toi de voir.

---

Normalement les objets seront sensés être encapsulé dans des shared_ptr pour pouvoir s'éviter la gestion manuelle de la mémoire tout en pouvant partager les ressources.

Citation:

---

Envoyé par Flob90

Ca c'est dans le cas où le renderer est nécessaire à l'ensemble de la classe material, si il ne sert que pour certaines fonction, alors je le laisserais en paramètre des fonctions qui en ont besoin.

---

Je me met cette remarque de côté car elle me semble être judicieuse!

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

#include <iostream>   struct X {};   struct A { A(int, float) { std::cout << "int, float" << std::endl; } A(double) { std::cout << "double" << std::endl; } A(int, X& ) { std::cout << "X&" << std::endl; } A(int, X&& ) { std::cout << "X&&" << std::endl; } };   template<typename T, typename... Args> T make(int a, Args&&... args) { return T(a, std::forward<Args>(args)... ); }   int main() { auto a = make<A>( 5, float(2) ); auto b = make<A>(2);   X x; auto c = make<A>(0, x ); auto d = make<A>(0, x ); auto e = make<A>(0, X() );   return 0; }

---

D'après ce code, il semblerait que std::forward soit là lors des passages par rvalues reference afin de la conserver. D'où le perfect forwarding?

Pour shared_ptr, tu as pris le temps de te demander quel devait être le cycle de vie des entités et arriver à la conclusion qu'il ne peut y avoir de responsable pour chaque entité ? Si non alors tu devrais reconsidérer la question, si tu sais exactement qui est responsable de chaque entité, alors un shared_ptr est superflus, un unique_ptr fera très bien son travail. Les shared_ptr sont là pour appliquer des politiques de responsabilités partagées, c'est un politique tout à fait viable, mais si elle est présente partout on peut légitimement se demander si il n'y a pas un problème de conception : aucun élément du design n'est responsable d'aucune entité ?

Imaginons un std::shared_ptr<texture>, il peut être crée par un utilisateur à n'importe quel moment, puis ce voir utiliser pour un mesh lors d'un rendu, pour faire du rendu dans cette texture et non à l'écran, etc.

Et un shared_ptr me semblait parfait car du coup il ne serait détruit que lorsque plus personne n'en aurait besoin. Est-ce une mauvaise direction?