Discussion :

[Kaamui]

Bonjour à tous.

Je souhaite créer un module qui gère la gravité et que je pourrais réutiliser dans tous mes futurs projets. Mais je veux pouvoir faire des choses (qui pour l'instant ne me servent pas) comme faire que plusieurs éléments dans un même environnement puisse subir des lois physiques différentes.

J'ai en tête un truc du genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
Gravity<Personnage> myGravity;
Gravity<IA> myGravity2;
 
myGravity.AddObject(J1);
myGravity.AddObject(J2);
for (int i=0; i< 100; i++)
   myGravity2.AddObject(IA(i));//ça ne me dérengerais pas que l'on puisse construire des objets au moment de leur ajout dans myGravity2 par exemple
//etc...
 
myGravity.Launch();//l'idée que ce soit en tache de fond ne me déplairait pas non plus...

Bref, ma problématique principale, c'est comment, si j'ai une classe template Gravity<T>, contraindre mon type T à posséder des coordonnées de type (x,y) ?

[3DArchi]

Salut,

1/ En laissant le compilateur lever une erreur...

2/ Il me semble (mais peut être dis-je une bêtise) que Boost.Type trait permet de construire ses propres traits + un assert.

3/ SFINAE pour faire de l'introspection :

Code :

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
#include <iostream>
 
template<class T>
struct test_member_x
{
   struct yes {char c;};
   struct no {char c[2];};
 
   template<class U, int U::*> struct tst_member{};
 
   template<class U>
   static yes test_f(tst_member<U,&U::x>*);
   template<class V>
   static no test_f(...);
 
   static const bool value = sizeof(test_f<T>(0))==sizeof(yes);
};
 
struct one
{
   int x;
   int y;
};
 
struct two
{
};
 
int main()
{
   std::cout<<std::boolalpha;
   std::cout<<test_member_x<one>::value<<"\n";
   std::cout<<test_member_x<two>::value<<"\n";
   return 0;
}

En passant par macro (nom et type du membre à tester), on peut généraliser test_member_x

[Kaamui]

Bonjour,

La vache je croyais pas que quelqu'un réussirait à me répondre !

Tout d'abord merci pur votre réponse.

3/...je vais déjà essayer de comprendre ce que vous avez fait là
Je comprends a peu près ce que vous faites mais j'ai du mal à assembler les dernières pièces du puzzle...

Déjà est-ce que les 3 petits points c'est une manière spécifier..."n'importe quoi"?
Ensuite, pourquoi ce "0" dans l'évaluation ?

Ces deux choses m'aideront je penses à finir de comprendre ce que vous m'avez proposé là, mais sinon...grandiose, franchement merci




Sinon pur la macro, je penses que ça va pas être beau... et pour l'instant je vois même pas comment m'y prendre, chaque chose en son temps

[3DArchi]

Déjà est-ce que les 3 petits points c'est une manière spécifier..."n'importe quoi"?

Les ... c'est une fonction à paramètre variadic comme printf. Elle peut de plus prendre (en théorie) n'importe quoi comme paramètre. On joue sur le fait que dans le choix de la fonction à appeler parmi les différentes disponibles, celle-ci est la moins prioritaire face à toute les autres. Donc quand le membre existe, deux fonctions sont candidates : la variadic et celle avec le pointeur sur la structure. C'est alors cette dernière qui est choisi. A contrario, lorsque le membre n'existe pas, celle avec les ... est la seule à convenir.
On s'appuie aussi sur le SFINAE (cf F.A.Q. Qu'est ce que le SFINAE) pour que le code compile sans erreur si le membre n'existe pas quand on essaie d'y accéder dans static yes test_f(tst_member<U,&U::x>*);. Donc quand le membre n'existe pas, on se tourne vers l'autre fonction (celle avec les ...).
Puis la taille des deux types retours pour savoir si c'est vrai ou faux.

Ensuite, pourquoi ce "0" dans l'évaluation ?

Les deux fonction test_f prennent un pointeur. 0 c'est tout simplement le pointeur nul (il n'existe pas en C++03). En C++11, on aurait pu utiliser nullptr
Ceci dit, pour ton problème, je laisserai le compilateur lever une erreur..

[Kaamui]

Vous pensez que cela n'est pas utile, pour ce que je fait ?

En tout cas, je viens encore d'apprendre des choses intéressantes,
et je vous en remercie.


Cordialement,

[3DArchi]

Salut,

Vous pensez que cela n'est pas utile, pour ce que je fait ?

S'il s'agit d'apprendre ces techniques, alors cela est utile.

S'il s'agit de contraindre le type générique, alors oui, je pense que je laisserais le compilateur râler.

Cette introspection peut servir à choisir entre différents traitements selon la présence ou non de certaines propriétés.

Pour vérifier si un paramètre générique contient bien le membre que tu utilises ... ben le compilateur le fait déjà. Au mieux tu fais avec un static_assert un message d'erreur un peu plus lisible mais c'est même pas sur. Au pire, tu risques de n'être pas à jour au fur et à mesure de l'évolution de ton code.


Autre chose, à la lecture des noms, je suis surpris que Gravity prenne en paramètre Personnage ou IA. Je flaire une mauvaise piste de design.

[Joel F]

Pour vérifier si un paramètre générique contient bien le membre que tu utilises ... ben le compilateur le fait déjà. Au mieux tu fais avec un static_assert un message d'erreur un peu plus lisible mais c'est même pas sur. Au pire, tu risques de n'être pas à jour au fur et à mesure de l'évolution de ton code.

Apres moults experiences, y a deux trucs a considerer :

- utiliser un truc genre Boost.Concept pour checker que le type verifie le Concept dont on a besoin. La SFINAE est plus utile pour la selection de surcharge que le test d'erreur.

- utiliser la SFINAE mais pour sauter dans une fonction trampoline permettant d'eviter l'error cascading. Souvent on test avec une static_assert puis on fait le traitement. Sauf que le compilo compile tout et on a la static_assert ET les erreurs, rendant le message illisible. Donc, on utilise la SFIANE pour sauter soit dans une implementation qui ne fait que la static_assert, soit dans le vrai code.

[Kaamui]

Oui c'est plus pour apprendre.


Pour l'architecture, ce que je souhaite, c'est avoir un module dans lequel je peux intégrer un nouvel objet quand je le souhaite (pas que ce soit automatique, on sait jamais, je pourrais avoir besoin qu'un objet parmi 1000 ne subissent pas la gravité). Je peux aussi avoir besoin que différents classes "frères et sœurs" ne subissent pas les même lois physiques. D'où les exemples avec IA et Personnage.

Le nom Gravity est peut-être un peu restrictif car il risque de remplir plus de fonctionnalités que ça si un jour il arrive à terme.

Juste pour être sur de vous suivre, vous cous attendiez à quoi comme paramètre pour T.

@ Joel F : j'en prend bonne note, et au moment ou je devrai faire un choix pour l'approche à ce sujet, je reviendrai lire votre réponse


Bonne année à vous 2 au fait.

Cordialement,

[3DArchi]

Juste pour être sur de vous suivre, vous cous attendiez à quoi comme paramètre pour T.

Quelque chose de plus concrètement lié à un calcul de la gravité (un algorithme, un parametrage, une politique ...). Personnage est un élément qui est soumis à une certaine gravité. IA ???.
Posons 2 questions simples :
=> quelle est la responsabilité de Gravity ?
=> (et pour reprendre celle de Joel) : quel est le concept de son paramètre générique ?