Pourquoi écrire des foncteurs ?

Code:

---

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

bool MaFonctionDeTri(const type & rl,const type & rr) { return rl < rr; }   struct MonFoncteurDeTri { bool operator()(const type & rl,const type & rr) { return rl < rr; } };

---

Je trouve la seconde écriture assez lourde et moins lisible.
Dans quel cas est-il avantageux de l'utiliser lorsqu'on a un prédicat à passer en paramètre à une fonction de <algorithm> ?
Merci pour vos retours d'expérience.

L'opérateur () d'une structure est résolu à la compilation et peut être inliné, alors qu'un pointeur sur fonction laissera toujours une indirection à l'exécution et empêchera toute optimisation.

Dans certains cas cela a peu d'importance, dans d'autres cela en a énormément (utilise std::sort avec les deux, tu verras ;)).

De plus, un foncteur peut porter un contexte (via ses données membres), ce que ne peut pas faire une fonction non-membre.

Citation:

---

L'opérateur () d'une structure est résolu à la compilation et peut être inliné, alors qu'un pointeur sur fonction laissera toujours une indirection à l'exécution et empêchera toute optimisation.

---

Les deux peuvent tout aussi bien être optimisés. Il me semble qu'à une époque il y avait un bug dans GCC qui lui empêchait d'optimiser les pointeurs de fonctions, mais y'a pas de raison pour que l'un s'optimise et pas l'autre.

Utiliser un foncteur permet d'avoir autre chose qu'une fonction libre, et donc d'avoir en particulier un contexte et un état.
Ça permet aussi de fournir différentes surcharges.

Citation:

---

Envoyé par loufoque

Les deux peuvent tout aussi bien être optimisés.

---

C'est vrai en théorie. En pratique, il semble que ce soit bien plus simple dans un cas que dans l'autre.

L'utilisation d'un foncteur plutôt qu'une fonction libre peut être aussi agréable lorsque le code qu'il doit contenir est important et qu'il doit donc être découpé en sous-fonctions. Dans le cas d'une fonction libre, on va se retrouver avec tout un tas de fonctions libres. Personellement, je n'aime pas trop ça. Alors qu'avec un foncteur, on peut tout mettre dans un foncteur ( et éventuellement utiliser la ruse décrite ici ). Mais bon, là c'est assez subjectif.

Tout a fait. Je viens d'essayer avec VC2005 et GCC 3.4.4, dans les deux cas std::sort avec une fonction est environ deux fois plus lent que std::sort avec un foncteur.

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

#include <iostream> #include <algorithm> #include <cstdlib> #include <ctime>   inline bool fonction(int a, int b) { return a < b; }   struct Foncteur { bool operator()(int a, int b) const { return a < b; } };   int main() { int const n = 1000; int v0[n]; for(int i = 0; i < n; ++i) { v0[i] = std::rand(); } int v[n]; for(int j = 0; j < 5; ++j) { std::clock_t t0 = std::clock(); for(int k = 0; k < 10000; ++k) { std::copy(v0, v0 + n, v); std::sort(v, v + n, fonction); } std::cout << double(std::clock() - t0)/CLOCKS_PER_SEC << '\n'; } }

---

Sous VC++6 le foncteur est 4-5% plus rapide. Bien que ce soit peu significatif, c'est tout de même surprenant de ne pas avoir les mêmes performances !

Bon ben va pour le foncteur() alors :D

T'as bien testé en Release ? Chez moi même sous VC++6 le foncteur est 30 à 40% plus rapide.

Tiens oui, effectivement 8O
Je m'étais contenté de tester nonchalamment en debug sous l'edi.

MSVC6 ? Essaie avec un compilateur C++. (MSVC 7.1 minimum)

MSVC++6 est bien un compilateur C++, non ?
C'est vrai, il a 10 ans. Je suis preneur pour un nouvel environnement C++ multiplateformes (EDI), j'aimerais me débarrasser de quelques mauvaises habitudes. Des suggestions ?

Retour aux foncteurs.
Je me suis rendu compte d'un curieux phénomène. Comment est fait la distinction entre le constructeur par défaut et le foncteur ?

Code:

---

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

struct Foncteur { Foncteur() {} bool operator()(int a, int b) const { return a < b; } };   ..   std::lower_bound( .., .., .., Foncteur());

---

J'ai un exemple de code où le constructeur par défaut est appelé juste avant un appel à std::lower_bound, pour "rien" semble-t-il. Le code semble s'exécuter correctement par ailleurs.

Ben il faut bien construire ton objet foncteur non?

Euh... "objet foncteur" ?
Si j'ai bien compris, un foncteur est une classe (ou structure) dont l'operator() est surchargé.
Par ailleurs, l'appel à std::lower_bound() a besoin de l'adresse de cet opérateur (pour son exécution) et non une référence d'objet. Je parle ici du quatrième paramètre de lower_bound, pas du troisième.
D'un autre coté, il y a une certaine logique dans ce que tu dis.
Ainsi, dans mon cas j'ai du code inutile (un constructeur par défaut) qui s'exécute à chaque "référence" (je ne sais comment l'exprimer) de l'operator(). Je n'ai nullement besoin d'initialiser quoi que se soit lors de l'appel vers cette fonction. Je vais donc devoir mettre mes operator() dans des classes spécifiques et épurées.
Comprenez-vous ce que je veux dire ?

Code:

---

1 2	std::lower_bound( .., .., .., Foncteur());

---

Foncteur() est le constructeur de Foncteur. Tu n'es pas obligé d'écrire explicitement le constructeur par défaut s'il ne fait rien de spécial ( tu peux l'enlever ).

Considère le code suivant:

Code:

---

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

bool test( int a, int b, Foncteur f ) { return f( a, b ); // appel à l'opérateur () }   int main() { test( 1, 2, Foncteur() ); // appel au constructeur }   // ou alors:   int main() { Foncteur f; // appel au constructeur test( 1, 2, f );   }

---

Je pense que ce que tu n'as pas compris, c'est qu'un foncteur est bien une instance de classe, qu'on construit, utilise via son opérateur (), puis détruit. Tu pourrais écrire ton code comme ceci de manière équivalente :

Code:

---

1 2	Foncteur f; std::lower_bound( .., .., .., f);

---

Ceci-dit dans les cas où les constructeurs / destructeurs sont inutiles, ils seront très bien éliminés à la compilation.

Maintenant tu pourrais très bien utiliser le constructeur à des fins plus utiles :

Code:

---

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

struct Foncteur { Foncteur(int x) : n(x) {} bool operator()(const A& a) const { return a.get() == n; }   int n; };   ..   std::find(v.begin(), v.end(), Foncteur(5));

---

Exemple bidon d'une recherche d'un membre ayant une donnée quelconque valant 5.

Oui... bien... je croyais avoir tout bien compris avec ces foncteurs, voilà que c'est plus nébuleux que jamais. Le code écrit depuis quelques semaines avec ces foncteurs fonctionne, mais je doute désormais de son efficacité...
Faut dire que la surcharge de l'operator() est un des actes les plus sombres de la programmation C++. Don't you think ? ;)

Nan nan ya pire. L'opérateur , en particulier.

Je ne sais plus qui me disait qu'au moment de leur introduction, tout le monde pensait que la surcharge des opérateurs () ou -> ou , ne servait à rien, et n'avait été ajoutée que par souhait de cohérence interne du langage. Et finalement, operator() permet les foncteurs, et operator-> permet les pointeurs intelligents. Pour operator, ils avaient probablement raison...

Pour la difference entre operator() et les () dans std::lower_bound( .., .., .., Foncteur()); c'est assez simple. Un opérateur ne peut être appelé que sur une ionstance d'une classe. Foncteur n'est pas une instance d'une classe, donc les () qu'il y a après signifient autre chose. En l'occurence, la création d'un objet temporaire.

Un autre avantage des foncteurs, je ne sais pas si il a été cité, c'est qu'ils n'ont pas le problème du ambiguous overload.

Par exemple, dynamic_pointer_cast<TypeDest> n'est pas utilisable comme callback.

Par contre, avec

Code:

---

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

template<typename To> struct dynamic_pointer_caster { template<typename T> struct result_type { typedef __decltype(dynamic_pointer_cast<To>(*(T*)0)) type; };   template<typename T> typename result_type<T>::type operator()(const T& t) const { return dynamic_pointer_cast<To>(t); } };

---

dynamic_pointer_caster<TypeDest>() marche très bien.

Merci à tous pour vos réponses et réflexions.
Avec l'usage je suppose que les bonnes habitudes viendront.

Aussi, ne pas oublier aussi de prévoir un opérator< dans ses classes. Pour les cas simples (ce qui est fort fréquent finalement) ça reste ce qu'il y a de mieux puisque c'est le "prédicat par défaut".