Traits pour représenter des hypotheses de modèles?

Salut!

C'est un peu le bazar dans mon framework de simulation. Du coup je veux rendre la vie un peu plus simple à l'utilisateur.

Le plus difficile c'est de se repérer correctement dans l'espace des modèles possibles. Du coup plutot que de donner un nom de classe à chaque modèle, je me demande si ce serait pas mieux de choisir une methode via une série de types (traits?) donnant les hypothèse du modèle. Le modèle / la fonction à appeler serait construit au compile-time, mais un patron multimethods permettrait de trouver la bonne fonction à appeler si ces choix se font au runtime via par exemple boost::program_options.

Du coup en pseudo code on pourrait faire un truc comme:

Code:

---

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

model = { no_selection, no_mutation, no_migration, non_overlapping_generation_times, random_mating, discrete_time };   simulate(model);

---

Ca peut marcher un truc comme ça, ou je dis n'importe quoi? :aie: C'est possible à terme de choisir la fonction/modèle à appeler au runtime, n'est-ce pas?

Dans l'idéal, pour ce genre de chose, on utilise une variable qui contient un mask binaire qui viendra activer ou non tout un tas de fonction:

Code:

---

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

typedef unsigned int eBine; // type recevant le mask enum bine // differentes valeur possible { val1 = 1, val2 = 1 << 1, val3 = 1 << 2, val4 = 1 << 3 };   eBine mask = bine::val1 | bine::val3; // la variable mask contiendra les valeur 'val1' et 'val3'   // pour savoir quelles sont les valeurs contenues: if ((mask & bine::val1) == bine::val1) executeCmd1(); else if ((mask & bine::val2) == bine::val2) executeCmd2();

---

Cela permet de faire des combinaisons par exemple:

Code:

---

1 2 3 4 5

#define MASKCONTAIN(var, value) ((var & value) == value)   if (MASKCONTAIN(mask, bine::val1) && MASKCONTAIN(mask, bine::val2) && !MASKCONTAIN(mask, bine::val3)) executeSpecialCmd();

---

De cette manière tu peux combiner plusieurs critère pour executer différente fonction. Dans ton cas, on pourrait imaginer de combiner discrete_time avec no_selection qui lancerait un algo différent par rapport à no_selection uniquement.




L'autre solution, c'est de passer par une factory pour pouvoir instancier la bonner classe en fonction du type que tu souhaites. De cette manière l'implémentation reste cachée pour ton utilisateur et tu conserve tes classes pour chacun des types de simulation (ce qui est beaucoup plus propre je pense :) ).

Ok je vois!
Pour etre sur de te comprendre, si je pars sur l'option Factory, ça renvoie un pointer sur une classe de base, ou bien le type est déterminé à la compilation? En gros, OOP ou générique?

Avec une factory, ça renvoit sur une classe de base, mais l'utilisateur de la lib n'a pas besoin de connaitre le nom de la classe fille ni son implémentation :)