Discussion :

[koala01]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

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
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

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

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 )

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

[JolyLoic]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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).

[Matthieu76]

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

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

[dalfab]

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 :

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
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

[Matthieu76]

Du coup, je fais un truc de genre ?

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
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 ?

[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.

[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.

[Bousk]

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 ?

Un truc comme

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
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.

[Matthieu76]

Ca revient au m�me que ce que j'ai propos� sauf que �a :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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.

[koala01]

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 ), 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 )

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

[Matthieu76]

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

En plus :

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
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.

[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 ?
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.

[koala01]

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

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 ) 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 ).

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.

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

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