choix d'une fonction en argument : lambda, class ou structure ? #optimisation

Version imprimable

Bonjour, je bosse sur de l'algorithmie et je suis confronter à un problème de conception et d’optimisation.

Comment faire pour choisir une fonction en paramètre de manière efficace ?
En gros je veux un truc du genre :

L'utilisateur de la lib définie :

Code:

Algo *test = new algo(cosinus); // le cosinus provenant d'une enum

Et dans le constructeur de Algo, un truc du genre:
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 enum functionEnum { cosinus, sinus, tangent }; class Algo { public : Algo(functionEnum e) { if(e == cosinus) func = [](float x) { return cos(x); }; else if(e == sinus) func = [](float x) { return sin(x); }; else if(e == tangent) func = [](float x) { return tan(x); }; } private : float func; }
Cela fonctionne très bien mais j'aimerais externaliser mes fonctions dans un autre ficher pour des raison de lisibilité. Dois-je faire une class static avec pour stocker mes fonctions ? Du coup, plus besoin de lambda ? Ou alors est-il plus propre de faire une class dérivé d'Algo pour chaque fonction ? Sinon je peux faire une structure contenant un pointer vers la fonction mais cela est trop car en réalité il s'agit de réseaux de neurones et je ne peux pas créer un pointer vers une fonction par neurones, cela serait trop lourd et ferait trop de répétission, non ? D'ailleurs, les lambda/pointers de fonction sont-ils stocker dans le tas ou la pile ?

Bien évidemment cela doit rester le plus optimiser possible car les fonctions sont appelé plusieurs 100^ène de milliers de fois pas seconde.

PS : Les cos, sin et tan ne sont ici que pour l'exemple, mes fonctions sont en réalité un peu plus complexes et plus nombreuses que cela et c'est aussi pour cela que je ne peux pas directement mettre mes fonctions dans ma classe Algo.
D'ailleurs il ne s'agit pas juste d'une fonction mais d'un couple de fonction : la fonction et sa dérivée associé.

Merci d'avance pour votre aide :mrgreen:

Et un truc comme cela, mais niveau performances je ne sais pas si c'est bon :whistle:

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
#include <iostream>
 
 
typedef enum e_func_name {
    func_name_cosinus = 0,
    func_name_other,
    func_name_sinus,
    func_name_tangent,
    func_name_unknown,
    NB_FUNC_NAMES
} FUNC_NAME;
 
 
template<FUNC_NAME func_name>
class Algo
{
public:
 
    void operator() () {
        std::cout << "Algo : default" << std::endl;
    }
};
 
 
template<>
class Algo<func_name_cosinus>
{
public:
 
    void operator() () {
        std::cout << "Algo : cosinus" << std::endl;
    }
};
 
 
template<>
class Algo<func_name_sinus>
{
public:
 
    void operator() () {
        std::cout << "Algo : sinus" << std::endl;
    }
};
 
 
template<>
class Algo<func_name_tangent>
{
public:
 
    void operator() () {
        std::cout << "Algo : tangent" << std::endl;
    }
};
 
 
class Execute_Algo
{
public:
 
    template<FUNC_NAME func_name>
    inline void run() {
        Algo<func_name> algo;
 
        algo();
    }
 
 
    inline void run(unsigned short name) {
        switch(name) {
        case func_name_cosinus: run<func_name_cosinus>(); break;
        case func_name_sinus:   run<func_name_sinus>();   break;
        case func_name_tangent: run<func_name_tangent>(); break;
        default: run<func_name_other>(); break;
        }
    }
};
 
 
int main()
{
    Execute_Algo exec;
 
    std::cout << "**** Static ****" << std::endl;
 
    exec.run<func_name_cosinus>();
    exec.run<func_name_other>();
    exec.run<func_name_sinus>();
    exec.run<func_name_tangent>();
    exec.run<func_name_unknown>();
 
    std::cout << std::endl << "**** Inside a loop ****" << std::endl;
 
    for (unsigned short name; name < NB_FUNC_NAMES; ++name) {
        exec.run(name);
    }
 
    return 0;
}

14/02/2018, 09h46
Bktero

Ce que tu souhaites faire ressembler bigrement au design pattern "stratégie" : https://www.tutorialspoint.com/desig...gy_pattern.htm

Dans ton cas précis (mais qui est peut-être trop limitant), pourquoi ne pas se contenter d'un pointeur sur fonction ?

Citation:

Envoyé par foetus

Et un truc comme cela, mais niveau performances je ne sais pas si c'est bon :whistle:

Merci de ta réponse.
Ta solution paraît un peu complexe et ce qui me dérange beaucoup c'est le switch la fonction run.

J'y ai réfléchie et es-ce que ça serait une bonne solution ?
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 Class Aglo { public : Algo() { switch(name) { case func_name_cosinus: function = FuncList::cosinus(x); break; // etc. } } private: float function; } Class FuncList { public: static float cosinus = [](float x)->float { return std::cos(x); }; // etc. }
Faut encore que je vois si je dois utiliser des lambdas ou des pointers de fonction, mais en gros, j'ai une list de fonction dans une classe static et dans le constructeur de Algo je fais pointer ma variable function vers la fonction que je souhaite utiliser.

Es-ce une bonne manière de faire ?

Puis-je faire pointer une variable vers un lambda ou dois-je utiliser des pointers de fonction ?

Citation:

Envoyé par Bktero

Ce que tu souhaites faire ressembler bigrement au design pattern "stratégie"

Oui, c'est à peu près ça mais il est impossible de faire des interfaces en C++ ?

Citation:

Envoyé par Bktero

Dans ton cas précis (mais qui est peut-être trop limitant), pourquoi ne pas se contenter d'un pointeur sur fonction ?

Effectivement je pense qu'il s'agit de la bonne solution mais je n'ai jamais utiliser des pointeurs sur fonction.
Je fais faire une classe static regroupant des templates contenant 2 pointeurs sur fonction, la fonction ainsi que sa dérivée.
et ensuite je choisirais le template dans le constructeur.

Citation:

Envoyé par Matthieu76

Bonjour, je bosse sur de l'algorithmie et je suis confronter à un problème de conception et d’optimisation.

Je veux bien entendre que vous êtes confronté à un problème de conception, mais j'ai des doutes sur l'optimisation. L'optimisation à priori est la racine de tous les maux.

Vous avez besoin de créer un objet dont le comportement diffère en fonction d'une donnée d'entrée (le type de fonction sous-jacente). Son comportement diffère en utilisant en interne des fonctions externes (?) pour traiter les données qui lui seront fournies durant son utilisation. Je suppose que le traitement de ces données est gourmand en ressources, tant en terme de mémoire que de calcul. À côté de ça, une unique indirection est complètement négligeable.

Dans un premier temps, concentrez-vous sur ces éléments de conception pour écrire un code facile à lire, à comprendre, à maintenir, etc. Une fois cela fait, si vous rencontrez des soucis de performance, vous pourrez profiler votre application pour détecter où du temps/de la mémoire est inutilement perdu.

Plusieurs angles d'attaque s'offrent à vous :

Laisser l'utilisateur de la classe Algo fournir les fonctions sous-jacentes ;
Déduire les fonctions sous-jacentes en interne en fonction d'un indice d'entrée (comme un flag).

Pour l'option #1 :
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 #include <iostream> #include <cmath> // Definition class Algo { public: using function_type = double(*)(double); // une fonction prenant un double et retournant un double (par exemple) private: function_type _function; function_type _derivative; public: Algo(function_type function, function_type derivative) : _function(function), _derivative(derivative) {} double do_some_work(double value) const { return 3.0 * _derivative(value) / _function(value); } }; // nota: Algo pourrait être templetisé selon le type de fonction sous-jacente ; cela améliorerait même sa lisibilité int main() { // Usage auto algo_sin = Algo{std::sin, std::cos}; std::cout << algo_sin.do_some_work(22.0/7) << "\n"; }
Pour l'option #2 :
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 35 36 37 #include <iostream> #include <cmath> #include <tuple> // Definition class Algo { public: enum algo_type { sinus, /*...*/ }; private: using function_type = double(*)(double); // par exemple static function_type function(algo_type type) { return std::get<0>(function_and_derivative(type)); } static function_type derivative(algo_type type) { return std::get<1>(function_and_derivative(type)); } static std::tuple<function_type, function_type> function_and_derivative(algo_type type) { switch (type) { case sinus: return std::make_tuple<function_type, function_type>(std::sin, std::cos); // ... } return std::make_tuple(nullptr, nullptr); } function_type _function; function_type _derivative; public: Algo(algo_type type) : _function(function(type)), _derivative(derivative(type)) {} double do_some_work(double value) const { return 3.0 * _derivative(value) / _function(value); } }; int main() { // Usage auto algo_sin = Algo{Algo::sinus}; std::cout << algo_sin.do_some_work(22.0/7) << "\n"; }
Il s'agit d'implémentations minimales qui sont très restrictives et ne fonctionnent que si les fonctions sous-jacentes à utiliser sont définies comme fonctions au sens de C++. Dans le cas où il est nécessaire de composer des fonctions sans devoir les définir (par exemple pour pouvoir définir à la volée -sin à partir de sin), il sera nécessaire d'ajouter une couche d'indirection, comme par exemple définir Algo::_* comme std::function<double(double)> par exemple. Cela permettrait d'écrire quelque chose comme auto algo_sin = Algo{std::cos, [](double v) { return -std::sin(v); }};. (live demo)

Les différentes options on des avantages et inconvénients qu'il vous faudra étudier. Dans le cas de #1, l'utilisateur de la classe peut définir les fonctions qu'il veut, rendant la classe plus versatile et universelle. Dans le cas #2, la classe a plus de contrôle sur l'usage qu'il en est fait, seules des fonctions prédéfinies sont utilisables. Mais dans tous les cas, les fonctions sous-jacentes peuvent être définies dans un autre fichier source, voire dans un autre binaire. Quant à l'usage de std::function, si l'appel à operateur() à chaque traitement de données a un impact mesuré comme négatif sur les performances de votre application, il vous est possible et mettre en cache l'indirection pour qu'elle n'ait lieu qu'une unique fois. Mais il s'agit là d'un autre problème.

J'aurais tendance à faire simple ;)

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
#include <array>
 
typedef int (*my_2_int_operand)(int, int);
 
int myadd(int a, int b)
	{ return a + b; }
 
int mysub(int a, int b)
	{ return a - b; }
 
int mymul(int a, int b)
	{ return a * b; }
 
constexpr std::array<my_2_int_operand, 3> my_2_int_funcs = { myadd, mysub, mymul };
 
enum my_2_int_enum
{ myadd_e, mysub_e, mymul_e };
 
 
typedef float (*my_1_float_operand)(float);
 
float mysin(float f)
	{ return sin(f); }
 
float mycos(float f)
	{ return cos(f); }
 
float mytan(float f)
	{ return tan(f); }
 
constexpr std::array<my_1_float_operand, 3> my_1_float_funcs = { mysin, mycos, mytan };
 
enum my_1_float_enum
{ mysin_e, mycos_e, mytan_e };
 
 
int run_2_int_algo(int a, int b, my_2_int_enum e)
	{ return my_2_int_funcs[e](a, b); }
 
float run_1_float_algo(float f, my_1_float_enum e)
	{ return my_1_float_funcs[e](f); }
 
 
int main()
{
	int i = run_2_int_algo(5, 12, myadd_e);
	float f = run_1_float_algo(3.14159f, mysin_e);
	return 0;
}

Les fonctions dans un .cpp, les enum et la définition des 2 fonctions run_algo dans un .h, et ta logique d'appel ailleurs dans ton code.
C'est à la fois lisible, simple et performant, un tableau prédéfini à la compilation étant plus rapide qu'un switch au runtime.
En supposant que j'aie compris la demande :D

Citation:

Envoyé par prgasp77

Je suppose que le traitement de ces données est gourmand en ressources, tant en terme de mémoire que de calcul. À côté de ça, une unique indirection est complètement négligeable.

Bah en fait je bosse sur des réseaux de neurones et ma fonction est appeler environ 125 millions de fois par seconde. Donc oui, il s'agit bien d'un problème d'optimisation ! Utilise un switch ou un if dans ma fonction est inconcevable c'est pour cela que je passe par des pointeurs de fonction. C'est ça ou alors faire une classe enfant pour chaque couple fonction/dérivé.

Citation:

Envoyé par prgasp77

Laisser l'utilisateur de la classe Algo fournir les fonctions sous-jacentes ;
Déduire les fonctions sous-jacentes en interne en fonction d'un indice d'entrée (comme un flag).

En gros je voudrais utiliser l'impémentation de la solution 1 mais ou l'utilisateur passe un enum en arguments du constructeur et dans celui-ci le pointeur sur fonction et défie par rapport à l'enum. (Je sais pas si je suis très clair)

Citation:

Envoyé par camboui

Les fonctions dans un .cpp, les enum et la définition des 2 fonctions run_algo dans un .h, et ta logique d'appel ailleurs dans ton code.

Oui c'est exactement ça que je veux merci.

Ça me donnera donc un truc du genre :
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 35 36 37 38 39 40 41 42 43 44 45 46 typedef float (*myFunc)(int, int); int myAdd(int a, int b) { return a + b; } int mySub(int a, int b) { return a - b; } int myMul(int a, int b) { return a * b; } enum myFuncEnum { add, sub, mul }; Class Algo { public : Algo(enum e, a, b) { this.a = a; this.b = b; if(e == add) algoFunc = myAdd; // etc. } void run() { for(int i = 0; i < 10000; i++) algoFunc(a, b); } private : myFunc algoFunc; int a; int b; int main() { Algo test(10, 5, add); test.run(); return 0; }
Avec surement quelques erreurs de syntaxe bien entendu ;)

14/02/2018, 14h26
prgasp77

Citation:

Envoyé par Matthieu76

Bah en fait je bosse sur des réseaux de neurones et ma fonction est appeler environ 125 millions de fois par seconde. Donc oui, il s'agit bien d'un problème d'optimisation !

Mettons-nous d'accord sur les termes. Pour optimiser, il faut une base de comparaison. On optimise pas à partir de rien. Si la définition au début du XXème siècle d'optimiser était faire au mieux, son sens actuel et notamment en informatique est :

Citation:

Optimiser
Rendre optimal, atteindre un optimum de production, obtenir le meilleur, selon un ensemble de critères, d'une chose ou d'une situation.

Il est donc question de modification, d'amélioration. Vous ne pouvez pas dès la conception optimiser, il vous faut un premier jet qui aura besoin, ou non, d'optimisation. Ce que j'essaie d'exprimer plus ou moins efficacement, c'est que vous devez vous soucier des contraintes temporelles de votre implémentation, mais vous n'êtes pas encore en phase d'optimisation. L'optimisation à priori est la racine de tous les maux (même à 125 MTPS).

Citation:

Envoyé par Matthieu76

[J]e voudrais utiliser l'impémentation de la solution 1 mais ou l'utilisateur passe un enum en arguments du constructeur et dans celui-ci le pointeur sur fonction et défie par rapport à l'enum.

C'est exactement ce que je décris dans ma seconde implémentation.

Bref, je vous invite à relire mon message ; il semble que vous soyez passé à côté de plein d'éléments importants. La question de l'obtention de pointeur de fonction à partir de types variés (std::function, lambda, fonctions libres...) y est par exemple traité. Et nulle part il est question d' "[utiliser] un switch ou un if dans [votre] fonction".
14/02/2018, 14h54
Bousk

Un switch étant un simple jump, je vois pas de quoi tu as peur d'en utiliser ? Surtout à priori. :weird:
Si tu veux vraiment des perfs, tu ne mets aucune indirection, et ta fonction serait un paramètre template de la classe.
14/02/2018, 15h10
bacelar

Citation:

Un switch étant un simple jump

Heu, non, c'est au minimum une comparaison + un jump, et surtout un méga bordel dans les mécanismes de prédiction de branches, le cache des instructions, des données, etc... :aie:
Tout ça pour voir que le seul moyen d'avoir des perf. convenables, c'est de faire ça dans le GPU donc avec rien de comparable à la solution "full CPU". 8O
14/02/2018, 15h20
prgasp77

Citation:

Envoyé par bacelar

un méga bordel dans les mécanismes de prédiction de branches, le cache des instructions, des données, etc... :aie:

Une expérience personnelle à partager ? On pourrait tous en profiter j'en suis sûr.

Salut,

Moi, d'un point de vue purement conceptuel, ce qui m'inquiète le plus, c'est d'avoir un switch ... case dans une (n'importe quelle! ) fonction.

Car, de manière générale, c'est une pratique qui ne respecte pas l'OCP (Open Closed Principle, ou principe "ouvert fermé").

Alors, je sais: on pourrait faire valoir que "des fonctions de trigonométrie, y en a pas des masses", que "le nombre de fonctions de trigonométrie est clairement établi" (sous entendu "il y a peu de chances que l'on vienne à devoir en rajouter une par la suite"), ou encore que "le but de cette classe est de respecter le DRY, en n'ayant du code à modifier qu'à un seul endroit en cas de besoin" et qu'il n'y a donc -- a priori -- aucune raison que l'on doive aller changer le code pour pouvoir ajouter une nouvelle fonctionnalité. Et je serai bien obligé d'être d'accord face à cette objection...

Seulement, j'ai un problème avec le nom de la classe utilisé lors de la question initiale : Algo (pour "algorithme", d'ailleurs pourquoi élider le nom :question:). Car le nom d'une classe indique l'utilisation que l'on peut en faire. Or, "algorithme", c'est comme "manager" ou "gestionnaire": ce sont des termes particulièrement vagues, qui nous incitent très facilement à prendre de mauvaises décisions.

Ainsi, si un jour, tu en viens à vouloir ajouter la fonctionnalité de calcul de la racine carrée (pour respecter le prototype de la fonction), tu as de grandes chances d'en arriver à te dire que "ben, finalement, ma classe Algo est idéal pour remplir ce besoin", et de décider d'ajouter cette fonctionnalité à ta classe Algo, dont tu avais au départ considéré qu'elle n'exécuterait ... que des fonctions de trigonométrie.

Et, bien sur, cela t'obligeras à ... aller modifier du code qui avait pourtant été validé, ce qui est en complet désaccord avec l'OCP.

Cela peut donc parraitre idiot, mais j'aurais sans doute moins d'objection si cette classe s'appelait Trigono (ou Trigo), car, au moins, cela éviterait le risque de prendre de mauvaises décisions :D

Enfin, le service rendu par ta classe consiste s'emble-t-il -- quoi qu'il arrive -- à faire appel à des fonctions existantes, et l'utilisation d'un callback semble donc parfaitement justifiée, l'idéal étant sans doute de fournir, tout simplement, la fonction qui devra être appelée au constructeur de ton instance, sous une forme qui pourrait être proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 class Algo{ public: /* j'utilise les fonctionnalités apparues en C++11... je ne m'inquiète pas des performances */ using callback_t = std::function<double (double)> Algo(callback_t callee):callee_{callee}{ } double callMe(double value) const{ return callee_(value); } private: callback_t callee_; };
(code non testé)
De cette manière, tu pourrais envisager d'écrire un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 /* converti des degrés en radians ;) */ double degToRad(double); int main(){ Algo sinus(std::sin); /* OU OU OU */ Algo specificThing([](double d) {return /* ... */ };); /* ... */ auto result1 = sinus.callMe( degToRad(35.11)); auto result2 = specificThing(3.1415926); /*...*/ }
Note d'ailleurs que la classe Algo pourrait tout aussi bien prendre une forme template, histoire d'accepter "n'importe quel type numérique" ;)

14/02/2018, 17h17
bacelar

Citation:

Alors, je sais: on pourrait faire valoir que "des fonctions de trigonométrie, y en a pas des masses"

Je trouve qu'il y a déjà la dose juste dans la norme en terme de fonctions numérique:
http://fr.cppreference.com/w/cpp/numeric/math

C'est pas une application de géométrie mais une simulation de neurones, les fonctions de modélisation de ces machins sont pléthores.
14/02/2018, 21h54
Bktero
Citation:

Envoyé par Matthieu76

Oui, c'est à peu près ça mais il est impossible de faire des interfaces en C++ ?

C'est évidemment possible ;)

Ce n'est pas exactement une interface au sens Java mais c'est très proche. Il s'agit d'une classe ne définissant que des fonctions membres virtuelles pures. Exemple :
Code:

1 2 3 4 5 class Algorithm { public: virtual T compute(U u, V v) = 0; };
Et voilà ! 8-)

PS : comme toute classe de base, elle devrait avoir un destructeur virtuel (ne faisant rien ici).
15/02/2018, 01h11
Matthieu76

Citation:

Envoyé par prgasp77

Ce que j'essaie d'exprimer plus ou moins efficacement, c'est que vous devez vous soucier des contraintes temporelles de votre implémentation, mais vous n'êtes pas encore en phase d'optimisation.

Pour l'instant je change le contenue de ma fonction directement dans le code puis je recompile. Je cherche une solution qui ne me coûterais pas plus que l'appel d'une fonction donc oui on peut dire que je suis en phase d’optimisation.

Et puis je trouve ça débile de ne pas réfléchir à l’optimisation dès le début !

J'ai des bouts de code où je me suis dis "on verra plus tard pour l'optimisation" et l'optimisation m'a fait changer toute l'architecture de mon programme ce qui m'a fait perdre beaucoup de temps alors que si j'avais réfléchie à l'optimisation au début j'aurais pû éviter de rechanger une partie de mon code.

Citation:

Envoyé par koala01

Moi, d'un point de vue purement conceptuel, ce qui m'inquiète le plus, c'est d'avoir un switch ... case dans une (n'importe quelle! ) fonction.

Je ne vois pas en quoi cela gène d'avoir juste un switch dans le constructeur de ma classe pour changer des trucs en fonction de mon paramètre d'entrée.

Citation:

Envoyé par koala01

cela t'obligeras à ... aller modifier du code qui avait pourtant été validé, ce qui est en complet désaccord avec l'OCP.

Roh ... ça va c'est juste un cas à rajouter dans le switch quand j'ajoute une fonction c'est pas la mort ! Et puis si on devait vraiment être en parfaite accord avec tout les principes de code on développerait plus rien ... Je vais pas faire un code 10 fois plus compliquer et moins clair et optimiser juste pour ne pas avoir à rajouter 1 ligne dans mon constructeur quand j’ajouterais une fonction tous les 36 du mois.

Citation:

Envoyé par koala01

des fonctions de trigonométrie, y en a pas des masses

Citation:

Envoyé par koala01

j'ai un problème avec le nom de la classe utilisé

Nan mais réfléchie 2 secondes, ma classe ne s'appelle pas réellement Algo et n'implémente pas des fonction trigonométriques, mon code est plus complexe que ça. J'ai fait ça pour être plus clair et puis si j'avais expliqué en détail mon code, tout le mode aurait fait des remarques sur le reste de mon code et personne n'aurait répondu à ma question exactement comme tu viens de le faire en critiquant le nom de ma classe. (Je dis ça par expérience ;))

En réalité dans mon code j'ai une classe NeuralNetwork contenant un vecteur de Perceptron aussi appeler neurones et c'est la fonction d'activation ainsi que la dérivée de fonction d'activation de mes perceptrons que j'aimerais choisir, avec une enum, à la création de mon réseaux de neurones. Il est vrai que j'aurais peut-être dû commencer par là. Et c'est pour cela que les pointeurs sur fonction s'y prête bien, comme ça tous mes neurones pointent vers la même fonction d'activation. Enfin j'aurais une fonction d'activation différente par couche mais ça c'est une autre histoire ...

Citation:

Envoyé par Bktero

Il s'agit d'une classe ne définissant que des fonctions membres virtuelles pures.

Merci j'avais pas pensé à ça, j'avais oublier le mot clé virtual. Du coup est-il possible de faire des méthodes qui prenne en argument une classe "interface" et de passer un enfant en argument ... Euh ... Bah oui évidemment je suis bête !
Même si dans mon cas cela ne m'aide pas beaucoup car ça serait trop lourd de refaire une classe pour chaque fonction alors que tout le reste de ma classe ne change pas d'un poil.

Bon, j'ai pris ma décision, je vais faire une classe abstraite contenant des pointeurs sur fonction et je vais faire un gros switch dans le constructeur de ma classe algo pour alloué la bonne fonction à la création de mon objet.

Ah et si quelqu'un pourrait m'expliquer comment son gérer les pointeurs de foctions en RAM ça serait très sympa. Es-ce que le code de la fonction et copier du tas à la pile lors de l’exécution ?

MERCI À TOUS.

Citation:

Envoyé par Bktero

PS : comme toute classe de base, elle devrait avoir un destructeur virtuel (ne faisant rien ici).

Pas forcément :

Si nous sommes bien dans le cadre d'une interface au sens "javaiste" du terme (comprend : d'une classe dont le seul but est de permettre d'exposer des fonctions dont le comportement doit être défini par celui qui les utilise), tu peux tout à fait envisager de placer le destructeur (non virtuel) dans l'accessibilité protégée, ainsi que le constructeur, selon toute vraisemblance.

Car il s'agit alors de classes:
dont on ne veut pouvoir créer une instance qu'au travers des classes dérivées (ce qui est une raison suffisante pour placer le constructeur dans l'accessibilité protégée
dont on veut refuser la création d'une instance en tant que telle (même si la présence d'une fonction virtuelle pure suffirait à cet effet)
dont on ne veut surtout pas permettre à l'utilisateur la destruction d'une instance dérivée si elle n'est connue que "en tant qu'instance de la classe de base"

Ce qui nous donnerait au final quelque chose comme
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 class MyInterface{ public: /* tant qu'à faire, enfonçons un peu le clou de la sémantique d'entité */ MyInterface(MyInterface const & ) = delete; MyInterface & operator = (MyInterface const &) = delete; virtual ReturnType do_something()/* const*/ = 0: protected: /* seules les classe dérivées auront accès au constructeur et au destructeurs * (qui ne font rien d'autre que leur comportement par défaut, en l'occurrence) */ MyInterface() = default; ~MyInterface = default; };
Note d'ailleurs que l'on pourrait s'écarter un peu de cette restriction propre à java (et à d'autres langages) qui veut qu'une interface ne soit composée d'aucune donnée, et que les fonctions que l'on y déclare seront dés lors forcément virtuelles pures.

Notre interface pourrait, en effet, être représentée sous la forme d'une classe tout à fait classique, avec des données membres qui lui sont propres, et nécessaires au bon fonctionnement des services qu'elle expose; par exemple
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 class Movable{ public: /* tant qu'à faire, enfonçons un peu le clou de la sémantique d'entité */ Movable(Movable const & ) = delete; Movable & operator = (Movable const &) = delete; /* pas besoin d'une fonction virtuelle : on définit très clairement le comportement */ void move(Type diffX, Type diffY){ /* il manque quelques tests "qui vont bien", pour s'assurer que * l'élément se dépalce "où il peut / a la capacité" d'aller ;) */ pos_ = Position{pos_.x + diffX, pos.y + diffY}; } /* on voudra sûrement connaître la position de l'élément */ Position const & position() const{ return pos_; } protected: /* on ne veut pas que l'utilisateur de cette classe puisse en créer une instance * "telle qu'elle" : il doit passer par une des classes dérivées */ Movable() = default; ~Movable() = default; private: /* la donnée membre qui permet le bon fonctionnement des services exposés */ Position pos_; }
L'énorme avantage, par rapport à la première solution, c'est que l'on ne sera pas obligé de définir le comportement (qui a tout lieu d'être identique) des fonctions exposées pour chaque classe pour laquelle nous souhaitons profiter de la possibilité de mouvement ;)
@bacelar : merci, cela semble confirmer mon point de vue :D

@Matthieu76

Citation:

Roh ... ça va c'est juste un cas à rajouter dans le switch quand j'ajoute une fonction c'est pas la mort ! Et puis si on devait vraiment être en parfaite accord avec tout les principes de code on développerait plus rien ... Je vais pas faire un code 10 fois plus compliquer et moins clair et optimiser juste pour ne pas avoir à rajouter 1 ligne dans mon constructeur quand j’ajouterais une fonction tous les 36 du mois.

C'est justement ce que je tentais d'expliquer: oui, bien sur, ce n'est pas "catastrophique", mais, d'un point de vue purement conceptuel, le simple fait de devoir modifier du code qui fonctionne pour pouvoir rajouter une fonctionnalité est une erreur.

Or, dans l'ordre "logique" des choses:
on veille d'abord et avant tout à ce que la conception soit correcte
ce n'est qu'une fois que l'on a une conception correcte que l'on prend en compte les spécificités du langage

Par exemple, ce n'est pas parce que C++ accepte l'héritage multiple, ou parce qu'il permet de déclarer une fonction virtuelle que l'on redéfini dans une accessibilité plus permissive (ou moins permissive) que l'accessibilité dans laquelle elle a été déclarée au départ que l'on peut dire "LSP ne nous permettrait pas cette relation d'héritage, mais comme C++ l'autorise, pourquoi s'en priver :question:"

En gros, si un principe conceptuel te donne un NO-GO, tu arrête ta réflexion dans la direction que tu avais prise, et tu cherche "une autre solution"

Citation:

Nan mais réfléchie 2 secondes, ma classe ne s'appelle pas réellement Algo et n'implémente pas des fonction trigonométriques, mon code est plus complexe que ça. J'ai fait ça pour être plus clair et puis si j'avais expliqué en détail mon code, tout le mode aurait fait des remarques sur le reste de mon code et personne n'aurait répondu à ma question exactement comme tu viens de le faire en critiquant le nom de ma classe. (Je dis ça par expérience )

A vrai dire, je n'avais pas lu ton message en entier et je m'étais arrêté au code :oops:

Mais tout cela n'est jamais qu'une raison de plus qui devrais t'inciter à respecter les principes SOLID (car j'ai parlé du O, mais les quatre autres ont aussi leur importance ;) )

15/02/2018, 08h47
Bktero

Citation:

Envoyé par Matthieu76

Merci j'avais pas pensé à ça, j'avais oublier le mot clé virtual. Du coup est-il possible de faire des méthodes qui prenne en argument une classe "interface" et de passer un enfant en argument ... Euh ... Bah oui évidemment je suis bête !
Même si dans mon cas cela ne m'aide pas beaucoup car ça serait trop lourd de refaire une classe pour chaque fonction alors que tout le reste de ma classe ne change pas d'un poil.

C'est tout le concept du pattern Stratégie. Tu as besoin d'un nouveau comportement à passer en paramètre du constructeur de NeuralNetwork ? Et bien tu implémentes une nouvelle fois l'interface PerceptronActivator et sa seule methode activate(). Enfin, ça c'est en Java : en C++, passer un std::function fait très bien l'affaire quand ton interface ne contient qu'une seule méthode ! ;)

[Mode digression]

Citation:

Envoyé par koala01

Pas forcément :

Oui. Mais bon ta technique ou ma technique, ça reste pour empêcher la destruction polymorphique depuis un pointeur sur le type de base. J'aurais peut-être du précisé : comme elle a une méthode virtuelle, elle devrait avoir un destructeur virtuel.

En C++, pour paramétrer une exécution, tu as deux possibilités :
- Un paramétrage statique, qui sera déterminé au moment où tu écriras le code, résolu à la compilation, et qui peut avoir un coût nul lors de l'exécution.
- Un paramétrage dynamique, qui peut varier en cours d'exécution, et a un coût (généralement raisonnable, mais un coût néanmoins).

Pointeur de fonction, switch, design pattern strategy avec appel de fonction virtuelle entrent tous dans la catégorie dynamique (ainsi que std::function, que je préfère généralement aux alternatives déjà évoquées).

Pour le paramétrage statique, la technique à utiliser est un paramètre template. C'est par exemple ce qui est utilisé pour les algorithmes de la STL (regarde std::sort).

Citation:

Pour l'instant je change le contenue de ma fonction directement dans le code puis je recompile.

Tu es donc dans le cas statique. Souvent, on écrit ce genre de code avec des fonctions, ce qui permet d'utiliser la déduction de type template, et simplifie l'écriture:
Code:

1 2 3 4 5 6 7 template<class Function> double algo(Function f, double val) { return f(2*val); } algo([](double d){return sin(d);}, 3.14);
Mais si tu veux avec une classe :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 template<class Function> class Algo { Algo(Function f) : myFunction(f) {} double exec(double d) { return myFunction(2*d);} } int g() { auto f = [](double d) {return sin(d);}; Algo<decltype(f)> algo(f); // Avec les class template argument deduction du C++ 17, ce code doit pouvoir se simplifier en Algo algo([](double d) {return sin(d);}); mais il faut un compilateur qui gère cette nouveauté algo(3.14); }

15/02/2018, 11h20
koala01
Citation:

Envoyé par Bktero

Oui. Mais bon ta technique ou ma technique, ça reste pour empêcher la destruction polymorphique depuis un pointeur sur le type de base. J'aurais peut-être du précisé : comme elle a une méthode virtuelle, elle devrait avoir un destructeur virtuel.

Ohoh... Sauf que:

1- Un constructeur dont tu ne parle pas au compilateur sera implémenté automatiquement sous une forme publique et non virtuelle, ce qui nous empêche d'utiliser la classe en question comme classe de base
Tout simplement parce qu'un appel à delete myBase; aura pour effet de nous laisser avec un objet partiellement détruit : seule la partie correspondant au type de base sera détruite, mais la partie correspondant à ses classes dérivées (directes et indirectes) ne le sera pas.

2- Dans le cadre spécifique de la création d'une interface, dont la seule utilité est d'ajouter un (des) comportements à une classe, il ne fait normalement aucun sens de permettre la destructions des instances des classes dérivées alors que nous ne les connaissons que comme des (pointeur sur des) instances de cette interface:

Pour concrétiser mes dires, reprenons l'exemple d'une interface Movable (quelle que soit la manière dont on la crée). Tu conviendras avec moi qu'il n'y a aucun sens à avoir une fonction qui serait proche de
Code:

1 2 3 void destroy(Movable * ptr){ delete ptr; }
Car il n'y a de sens qu'à détruire un objet concret que si on le connait soit comme étant de son type réel (un lion, si c'est un lion, une gazelle si c'est une gazelle) soit si on le connait comme étant du type générique dont il est le digne représentant (une classe Animal, dans ce cas particulier, pour le distinguer des insectes et des plantes).

3- L'utilisation d'un destructeur publique et virtuel éviterait -- bien sur -- la "destruction partielle" d'un objet, mais, cela ne couvre qu'une partie du problème, car, comme dirait l'autre

Citation:

nous devons faire en sorte que nos classes soient facile à utiliser correctement et difficiles à utiliser de manière incorrecte

En déclarant le destructeur d'une interface comme étant virtuel dans l'accessibilité publique, tu laisses à l'utilisateur de ton interface la possibilité de faire une connerie en l'utilisant; ce qui n'est jamais bon...

Alors, bien sur, on pourra me rétorquer que "mais personne n'aurait l'idée de détruire un objet alors qu'il ne le connaît sous la forme d'une de ses interfaces", et je serai bien obligé d'admettre que la pratique est pour le moins choquante.

Malheureusement, la loi de Finagle joue contre nous, et, s'il y a une chose que j'ai apprise depuis longtemps, c'est que l'utilisateur (quel qu'il soit, ce qui inclut tous les utilisateurs des classes que je développe, moi y compris) est un imbécile distrait, et que, si on lui laisse l'occasion de faire une connerie, ce n'est qu'une question de temps avant qu'il ne la fasse.

Si bien que la seule question intéressante à se poser est "quand va-t-il faire cette connerie", et que la réponse sera toujours la même "au pire moment qui soit possible de trouver". Car il ne sert en effet à rien de perdre son temps à se demander s'il risque ou non effectivement de la faire, vu que la réponse est forcément oui ;)

Donc, en gros, j'estime que la seule manière vraiment sécurisante de créer une interface (indépendamment du fait que l'on expose des fonctions virtuelles ou non) est bel et bien d'en définir le destructeur dans l'accessibilité protégée, sans qu'il soit déclaré virtuel ;)

PS: oui, je sais, je suis un vieux con chiant qui s'attarde sur des détails dont tout le monde se fout pas mal... Mais à mon age, on ne me refera plus :D
15/02/2018, 14h27
Matthieu76

Citation:

Envoyé par koala01

le simple fait de devoir modifier du code qui fonctionne pour pouvoir rajouter une fonctionnalité est une erreur.

Il est vrai que si je mets mon enum dans ma classe statique répertoriant mes fonctions et que j'utilise l'enum comme index d'un vector répertoriant mes fonction je ne devrais plus avoir besoin de modifier ma classe principale pour y ajouter une fonction. merci

Citation:

Envoyé par Bktero

Tu implémentes une nouvelle fois l'interface PerceptronActivator et sa seule methode activate().

C'est bizarre de devoir ré-implémenter une interface alors que je veux juste changer une fonction. Il ne s'agit pas d'un autre type de neurone mais c'est le même neurones avec une fonction d'activate différente. Ça serait illogique d'un point de vue conception d'avoir des 10e de classe du genre : NeuronSinus, NeuronCosinus, NeuronTangent, NeuronSqrt, etc. Même si elle hérite tous d'une même class abstraite Perceptron, c'est plus compréhensible je trouve d'avoir une seule classe qui prend en paramètre un pointeur de fonction. Comme ça je peux mieux regrouper et visualiser mes différente fonction d'activation.

Citation:

Envoyé par Bktero

en C++, passer un std::function fait très bien l'affaire quand ton interface ne contient qu'une seule méthode !

Oui, mais je vais plutôt opter pour des pointeurs de fonction que des std::function car dans mon code je peux créer par exemple 1000 neurones qui utilise tous la même fonction donc autant qu'ils pointent tous sur la même fonction et personnellement je trouve que faire des pointeurs de std::function tout comme des pointeurs de vecteur est complètement absurde :D

Citation:

Envoyé par JolyLoic

template<class Function>

Merci beaucoup même si je ne comprends pas trop cette ligne de code même si je sais ce qu'est basique un template mais un template de classe alors que c'est une fonction qui varie, pas une classe, je ne comprends pas tout... (J'irais voir plus tard sur internet)

Et encore merci à tous !

Ceci étant dit, si tu travailles sur base d'une énumération (reprenons l'idée des seules fonction trigono, par facilité) proche de
Code:

1 2 3 4 5 6 7 enum WichFunction{ sinus, cosinus, tangeante, /* ...*/ MAX // TRES important, tu verras pourquoi ensuite };
Le fait de travailler avec une classe prenant, pour la cause, une forme proche de
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 class Algo{ /* je suis un gros fade, j'ai horreur de me répéter sur des noms de type trop complexes */ using tab_t = std::vector<double (*) (double>; /* quitte à ne pas respecter l'OCP, respectons le SRP */ static tab_t const & allFunctions(){ static const tab_t funcs{&std::sin &std::cos, &std::tan /*, ... */}; /* on se permet d'engueuler l'implémenteur si le nombre de fonctions indiquées * ne correspond pas au nombre de valeur énumérées */ assert(funcs.size() == MAX && "Implementor!!! Please do your job !!!"); return funcs; } public: /* chaque fois que l'on veut utiliser l'algorithme, il faut préciser la fonction qui sera utilisée */ Algo(WichFunction f):f_{f}{ /* L'utilisateur est un imbécile distrait qui pourrait nous servir un Algo bad(static_cast<WichFunction>(127); */ assert(f< MAX && "bad function requested"); } double exec(double d) const{ return allFunctions()[f_](d); } }
Alors, je sens que tu vas m'objecter que c'est sensiblement la même chose que d'avoir un switch, qu'il soit dans le constructeur ou dans la fonction... Sauf que :
1- D'un point de vue conceptuel, on se rajoute un garde fous: on ne peut pas ajouter une valeur énumérée (avant MAX, ca va de soi) ou une fonction sans rajouter son pendant de "l'autre coté".

J'aurais, bien sur, préféré une erreur de compilation, à ce sujet, ce qui devrait être possible, vu que les valeurs énumérés sont des constantes de compilation, mais, si tu oublies l'un des deux, le premier test qui utilisera Algo te rappellera à l'ordre :D

Bien sur, tu pourrais demander au compilateur de te lancer un avertissement sur les valeurs énumérées absentes de ton switch... case, mais, qui s'en inquièterait :question:

2- Sans préjuger le moins du monde des optimisations que peut faire le compilateur sur un switch ... case, l'utilisation d'un tableau limite l'action à ... un décallage d'adresse dans le tableau, sans test pour savoir quelle valeur nous intéresse.

Toi qui veut des performances, tu sera servi, car à ce titre, tu ne trouveras sans doute pas mieux (même si un bench correct est nécessaire pour confirmer cette assertion ;) ) :D

3- Quitte à ne pas respecter l'OCP (car je peux admettre que ce ne soit pas toujours possible), je limite au maximum la protée de ce non respect.

J'aurais d'ailleurs pu en faire une fonction libre qui ne soit pas déclarée dans le header, et qui serait juste présente dans le fichier d'implémentation, mais j'aurais perdu les possibilités d'inlining ;)

16/02/2018, 01h27
JolyLoic
Citation:

Envoyé par Matthieu76

Merci beaucoup même si je ne comprends pas trop cette ligne de code même si je sais ce qu'est basique un template mais un template de classe alors que c'est une fonction qui varie, pas une classe, je ne comprends pas tout... (J'irais voir plus tard sur internet)

Qu'est-ce qu'une fonction ? Un truc que l'on peut appeler en mettant des parenthèses derrière avec des paramètres, et qui peut retourner une valeur.

Dans ce code, a est-il une fonction ?

Code:

int i = a(2, "Test");

On pourrait penser que oui, et ça pourrait être vrai. Mais pas forcément. a peut aussi être un objet :
Code:

1 2 3 4 5 6 7 8 9 10 11 class A { int operator()(int i, string const &s) { return 42; } }; void f() { A a; int i = a(2, "Test"); }
On nomme généralement foncteur tout ce qui peut être appelé (une fonction, un pointeur de fonction, un std::function (qui d'ailleurs n'est pas fait pour être manipulé par pointeur, mais directement, pour reprendre un autre point), une instance d'une classe ayant redéfini l'opérateur(), une lambda (qui est un cas particulier d'une instance de classe ayant redéfini l'opérateur()).

Et quand j'écris :
Code:

1 2 template<class Function> int f(int i, Function fct) {return fct(2*i); }
Je dis que ma fonction est paramétrée par un foncteur (qui peut être une classe ou pas, ici le mot clef class est sans signification, j'aurais pu écrire template<typename Function>). L'avantage est que si j’appelle f en lui passant une instance de classe, le code de l'opérateur() de cette classe est directement accessible quand on instancie le template, et c'est appel de fonction pourra être totalement inliné, chose bien moins facile pour le compilateur s'il manipule des pointeurs de fonction (y compris à l'aide de std::function).
16/02/2018, 10h41
Matthieu76

Citation:

Envoyé par JolyLoic

le code de l'opérateur() de cette classe

L'opérateur() pour une classe est son constructeur, non ?

Citation:

Envoyé par Matthieu76

L'opérateur() pour une classe est son constructeur, non ?

Non, absolument pas.
Le constructeur est utilisé au moment de la création de l'instance. L'opérateur() permet à l'instance d'être utilisée comme si c'était une fonction. Par exemple les lambda sont en fait des objets qui ont un opérateur().
Tous les objets qui ont au moins un operateur() sont appelés foncteurs.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 class UnLambda { int x_; public: UnLambda( int x ) : x_(x) {} // Un constructeur int operator()( int y )const { // Un opérateur fonction return x_ + y; } }; int x = 5; UnLambda lb{ x }; std::cout << lb(4); // l'objet est utilisé comme une fonction ===> 9 // ou bien il est totalement équivalent de faire int x = 5; auto lb = [=x]( int y ) { return x + y; } // défini l'objet, et le construit std::cout << lb(4); // ===> 9

Du coup, je fais un truc de genre ?

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
35
36
37
38
 
class TrigonometricFunction 
{
    int operator()(float x) = 0;
}; 
 
class Cosinus : TrigonometricFunction 
{
    int operator()(float x) { return cos(x); };
};
 
class Sinus: TrigonometricFunction 
{
    int operator()(float x) { return sin(x); };
};
 
class Tangent: TrigonometricFunction 
{
    int operator()(float x) { return tan(x); };
};
 
class ListFunction()
{
    Enum myEnum {cos = 0, sin, tan}; 
    vector<*TrigonometricFunction> list { new Cosinus(), new Sinus(), new Tangent() };
}
 
class Algo
{
    private:
        TrigonometricFunction *TrigoFunction;
 
    public:
        Algo(ListFunction::myEnum e)
        {
            TrigoFunction = ListFunction::list[e];
        }
}

En c'est pas plus long à exécuter que des pointeurs sur fonction ?

Et donc vous confirmez, je pars sur ça ?

16/02/2018, 15h02
Bousk

Pourquoi garder un switch et un choix de l'algo à l'exécution ? Comptes-tu vraiment changer d'algo en cours d'exécution ?
Pourquoi ne pas choisir l'algo à la compilation ce qui permettrait au compilo d'optimiser tout au maximum ? cf les posts de JolyLoic et mon idée initiale.
Si l'opérateur n'est pas virtuel il ne sera pas choisi avec le typage dynamique mais du typage statique. C'est une fonction comme les autres.
16/02/2018, 16h24
Matthieu76

Bousk, je ne veux pas que l'utilisateur définisse une fonction en paramètre mais choisisse parmi une enum donc l'idée JolyLoic ne me convient pas. Et pour ce qui est du switch, ne ne le veut pas à l'intérieur de ma fonction car cela ralentirait fortement mon algorithme et de plus ce n'est pas très beau niveau conception.

Pourquoi la solution que je propose ne te convient pas ? Si tu ne m'explique pas, cela ne m'aide pas à grand-chose.

Citation:

Envoyé par Matthieu76

Bousk, je ne veux pas que l'utilisateur définisse une fonction en paramètre mais choisisse parmi une enum donc l'idée JolyLoic ne me convient pas.

Tu cries après des perfs dès le début et tu rejettes la solution qui a le plus de sens à ce sujet... Qui a dit que l'enum était obligatoirement lié à un switch runtime ? :weird:

Un truc comme
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 template<class Func> struct BaseAlgo { void call(float a) { Func::call(a); } }; struct MyCos { static void call(float a) { std::cout << std::cos(a) << std::endl; } }; struct MySin { static void call(float a) { std::cout << std::sin(a) << std::endl; } }; enum class EnumParceQueCestMieux { Cos, Sin, }; using AllAlgos = std::tuple<MyCos, MySin>; template<EnumParceQueCestMieux ALGO> struct EnChoisissantParmiUnEnumCestPlusJoli { using Algo = typename std::tuple_element<static_cast<unsigned int>(ALGO), AllAlgos>::type; }; template<EnumParceQueCestMieux ALGO> struct Algo : BaseAlgo<typename EnChoisissantParmiUnEnumCestPlusJoli<ALGO>::Algo> { }; int main(int argc, char *argv[]) { BaseAlgo<MyCos>().call(3.0); auto pp = Algo<EnumParceQueCestMieux::Cos>(); pp.call(3.0); return 0; }
Tu as même un choix parmi un enum puisque tu y tiens tant. A la compilation.

16/02/2018, 17h46
Matthieu76
Ca revient au même que ce que j'ai proposé sauf que ça :
Code:

1 2 3 4 5 6 7 int main(int argc, char *argv[]) { BaseAlgo<MyCos>().call(3.0); auto pp = Algo<EnumParceQueCestMieux::Cos>(); pp.call(3.0); return 0; }
C'est 1 000 fois plus moche et moins clair que ça :
Code:

1 2 3 4 5 6 int main(int argc, char *argv[]) { Algo myAlgo(cos); myAlgo.call(3.0); // pour garder les même nom que dans ton exemple return 0; }
En encore une fois, ça change quoi que je passe par des templates ou par des classes ? Et tu ne m'as toujours pas expliqué en quoi ta solution était meilleure que la mienne.
21/02/2018, 14h01
koala01

Citation:

Envoyé par Matthieu76

En encore une fois, ça change quoi que je passe par des templates ou par des classes ?

L'énorme avantage des template, c'est que tout le travail est fait à la compilation, et que, du coup, le compilateur pourra t'engueuler (au moment de la compilation !!!) si, pour une raison ou une autre, tu fourni un paramètre template qui ne correspond pas à ce qui est attendu.

Tu auras donc une détection d'erreur bien plus tôt dans ton processus, et, de ce fait, tu sauras la corriger beaucoup plus facilement (enfin, une fois que tu te sera habitué à la diatribe du compilateur lorsqu'il travaille avec des template).

Car il faut savoir que, plus une erreur est diagnostiquée tôt, plus il est facile de la situer et de la corriger (car, le diagnostique se rapproche forcément du moment où tu as écrit le cod :D), et que le mieux est, effectivement, de s'aider du compilateur, car, a priori, tu tenteras une compilation de tes fichiers... directement après les avoir écrits (et donc, à un moment où le code qu'il contient est encore frais dans ton esprit :D )

Citation:

Et tu ne m'as toujours pas expliqué en quoi ta solution était meilleure que la mienne.

Ben, justement, pour la raison que je viens d'expliquer :D

Dans ce cas autant utiliser des templates partout au lieu de classe ??? Ça n'as pas de sens !

En plus :

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
template<class Func>
struct BaseAlgo {
	void call(float a) { Func::call(a); }
};
 
struct MyCos {
	static void call(float a) { std::cout << std::cos(a) << std::endl; }
};
struct MySin {
	static void call(float a) { std::cout << std::sin(a) << std::endl; }
};
 
enum class EnumParceQueCestMieux { Cos, Sin, };
using AllAlgos = std::tuple<MyCos, MySin>;
 
template<EnumParceQueCestMieux ALGO>
struct EnChoisissantParmiUnEnumCestPlusJoli {
	using Algo = typename std::tuple_element<static_cast<unsigned int>(ALGO), AllAlgos>::type;
};
 
template<EnumParceQueCestMieux ALGO>
struct Algo : BaseAlgo<typename EnChoisissantParmiUnEnumCestPlusJoli<ALGO>::Algo> {
};
 
int main(int argc, char *argv[])
{
	BaseAlgo<MyCos>().call(3.0);
	auto pp = Algo<EnumParceQueCestMieux::Cos>();
	pp.call(3.0);
	return 0;
}

Ce code est moche est imbitable, on comprend rien... Ma solution est beaucoup plus clair et plus simple, elle est mieux.

22/02/2018, 10h11
Bousk

Tu ne comprends rien. Pourtant ça reste du C++, et pas du plus velu.
On t'explique depuis 1 semaine que ce serait mieux mais t'es entêté à garder ton truc parce que tu estimes que c'est plus joli, plus clair et mieux. Arguments que je trouve vraiment étrange, mais bon, je suppose qu'un code joli et subjectivement mieux c'est une forme d'optimisation ? :weird:
Fais-toi plaisir, utilise ce que bon te semble après tout ça m'en touche une sans bouger l'autre.
Inutile de venir ici le ressasser pour t'en convaincre. :cfou:
22/02/2018, 10h44
koala01
Citation:

Envoyé par Matthieu76

Dans ce cas autant utiliser des templates partout au lieu de classe ??? Ça n'as pas de sens !

On ne dit pas de le faire *** partout ***, on dit juste de le faire *** partout où il est possible de le faire ***. Nuance :D

Il faut comprendre que, lorsque tu pars sur l'utilisation de fonctions virtuelles, et pour autant que ton code soit compris par le compilateur, tu dois attendre l'exécution de ton programme pour te rendre compte des éventuels problèmes posés par ton code.

C'est d'ailleurs la raison pour laquelle on bassine les gens avec l'intérêt de mettre une politique stricte de tests unitaires en place : parce que, plus une erreur est repérée tôt, plus tu auras facile à la corriger.

Mettons que tu aies un projet important, pour lequel tu dois ajouter une fonctionnalité, et qui nécessite de modifier une partie du code existant.

Une fois que tu as fait ta modification, si l'un des tests unitaires échoue (alors qu'il n'échouait pas avant la modification), tu sais que c'est ta modification qui est la cause de cet échec, et, comme tu viens d'apporter cette modification (avec un peu de chance, les fichiers que tu as modifiés sont même encore ouverts dans ton EDI), tu auras forcément "facile" à corriger le problème.

Par contre, si tu n'as pas de tests unitaires (ou si, pas de bol, tu n'en a pas qui touchent à la modification apportée), tu ne seras tenu au courant du problème que suite à ... un rapport de bug.

Le truc, c'est qu'il peut falloir trois mois, six mois ou un an avant que ce rapport de bug n'arrive, et que, comme tu auras continué à travailler entre temps, tu auras eu "tout le temps" d'oublier les détails de ce que tu auras fait. Et pire encore: tu risques d'avoir basé certaines évolutions ultérieures sur les comportements "fautifs".

C'est la raison pour laquelle la correction de bugs est si compliquée: on ne sait "plus trop" ce que l'on a modifié, ni pourquoi, et, surtout, les correctifs apportés risquent (car ce n'est -- par chance -- pas toujours le cas) de "casser" le code à d'autres endroits.

Seulement, si tu as cinq fonctions à mettre au point pour pouvoir ajouter une fonctionnalité, tu ne vas sans doute pas lancer toute la batterie de tests (qui peut parfois demander des plombes à s'effectuer) à chaque fois que tu as fini de travailler sur l'une de ces fonctions! tu vas sans doute attendre d'avoir... intégré ta nouvelle fonctionnalité, et d'être arrivé à compiler l'ensemble avant d'exécuter "tous les tests d'un seul coup".

Hé bien, il faut te dire que, si les tests te facilitent la vie, car ils te permettent de corriger les problèmes "plus tôt" que si tu avais du attendre un rapport de bug, la compilation en elle-même peut te permettre de repérer des erreurs encore plus tôt que les tests unitaires. Et qu'elle peut donc te faciliter encore d'autant plus la vie en apportant des solutions au problème encore plus tôt.

Car, si on peut s'attendre à ce que tu ne lance la batterie de tests unitaires qu'une fois "la nouvelle fonctionnalité développée", on peut malgré tout aussi s'attendre à ce que... tu lances une compilation (ne serait-ce que de chaque fichier que tu modifies)... dés que tu as fini la modification d'une fonction (entre autres, pour t'assurer que tu n'a pas fait de "stupides erreurs de syntaxe", comme oublier le ; final).

Le truc, c'est que le compilateur ne va pas se contenter de s'assurer que tu utilises la syntaxe appropriée: si tu lui cause correctement, il peut également s'assurer que toute une série de contrats qui seront passés entre toi (le développeur) et l'utilisateur (c'est peut-être aussi toi :D ) seront respectés scrupuleusement.

C'est ce qui fait que la programmation générique est d'une telle puissance en C++; car, si un contrat n'est pas respecté, le compilateur (sur lequel tu peux compter pour ne rien laisser passer) t'engueulera comme du poisson pourri et refusera de générer l'exécutable final.

Alors, nous sommes bien d'accord sur deux points: la programmation générique n'est pas la panacée, "le remède à tous les maux"; et la programmation générique est souvent complexe, ou, à tout le moins, sans doute plus complexe que la programmation orientée objets.

Mais un fait demeure: elle peut te simplifier énormément la vie aussi bien en termes de quantité de code à écrire (car tu peux observer un comportement identique pour plusieurs types de données) qu'en termes de détection d'erreur(même si les messages d'erreurs deviennent d'autant plus cryptiques :P ).

Dés lors, même si nous sommes bien d'accord sur le fait qu'il ne faut pas l'utiliser de manière systématique, pour n'importe quel type de problème, et que c'est d'autant plus vrai que certains problèmes se géreront bien plus facilement en utilisant d'autres paradigmes (comme l'orienté objet), il faut malgré tout se dire que, si on a le choix du paradigme, et que si le paradigme générique est "l'un des paradigmes possibles", on a -- très vraisemblablement -- le plus grand intérêt à le préférer à tout autre.

Citation:

Ce code est moche est imbitable, on comprend rien...

j'aurais tendance à dire que ce code te parait imbitable:
1. parce que tu n'a pas (encore) l'habitude du paradigme générique et
2. parce que les noms choisis ne sont pas forcément les plus clairs (entre autres: EnumParceQueCestMieux ou EnChoisissantParmiUnEnumCestPlusJoli
et que

Citation:

Ma solution est beaucoup plus clair et plus simple, elle est mieux.

Elle est sans doute plus claire (pour l'instant) pour toi, mais, de là à dire "elle est mieux", il y a un pas que l'on est loin de franchir aisément.
- parce que la virtualité des fonctions, c'est un processus qui prend du temps
- parce que la détection d'erreurs est reportées "au callendes grèques"
- parce que la programmation générique a un certain charme
- pour plein d'autres raisons que je ne mettrai pas ici ;)

Fuseau horaire GMT +2. Il est actuellement 08h36.