Pointeurs de fonction

Bonjour,

J'ai une méthode qui doit appeler une autre fonction. Cette fonction est choisie selon un paramètre enum de la méthode.

N'ayant pas envie que l'appelant de la méthode s'embête en fournissant la syntaxe de la fonction qui est appelée en un second temps, j'utilise donc un enum.

Cette fonction, qui reste donc à déterminer, est au sein de la méthode appelée plusieurs fois dans une boucle. Dans le corps de la boucle, je dois donc référencer une fonction que je ne connais pas encore. Ou plutôt, je dispose de plusieurs prototypes de fonctions, mais je ne sais pas encore laquelle utiliser.

Je pensais donc créer dans la méthode un pointeur de fonction, et une fois que je connais l'enum, je pourrai, via un switch, pointer vers la bonne fonction, puis utiliser le pointeur à ma guise.

Mais j'ai un problème de syntaxe : le type de retour des fonctions est identique, mais les signature des fonctions sont différentes (en nombre et type).

1 - comment déclarer le pointeur
2 -une fois connue la fonction vers laquelle il doit pointer, comment effectuer l'affectation ?

Merci.

Salut,

Je ne sait pas si c'est valable pour des pointeurs sur fonctions mais est ce que tu ne peux pas déclarer ton pointeur de départ comme un void * et ensuite le caster suivant tes besoins ?

Citation:

---

Envoyé par Higestromm

Je ne sait pas si c'est valable pour des pointeurs sur fonctions mais est ce que tu ne peux pas déclarer ton pointeur de départ comme un void * et ensuite le caster suivant tes besoins ?

---

Un pointeur de fonction n'est pas compatible avec un void*. De même qu'il n'y a pas compatibilité entre pointeurs sur fonctions à arguments différents.

Il existe boost::function et boost::bind, qui permettent d'adapter des fonctions pour les contraindre à une signature unique, je ne sais pas si ça peut te servir, puisque je n'ai pas compris ce que tu espèrerais pouvoir faire avec des pointeurs de fonction ayant des arguments non connus de la personne sensée les utiliser.

Ce que je veux, c'est qu'un utilsiateur appelle une fonction A avec un paramètre x, et qu'en fonction de la valeur de x, que A appelle une fonction B parmi n fonctions possibles.

Tu peux bidouiller en faisant en sorte que tes fonctions appelés aient les meme paramètres : des void * dont certains sont inutilisés ou bien une structure qui contient tes arguments...

Citation:

---

Envoyé par oodini

Ce que je veux, c'est qu'un utilsiateur appelle une fonction A avec un paramètre x, et qu'en fonction de la valeur de x, que A appelle une fonction B parmi n fonctions possibles.

---

Code:

---

1 2 3 4 5 6 7 8 9

void A(int x) { switch (x) { case 1: f(); break; case 2: g(42); break; default: h(x-1); break; } }

---

Je me doute que ce n'est pas ça que tu veux... Alors, si tu pouvais expliciter un peu plus ?

C'est ça, ajouté du fait que ce switch doit être suivi d'une procédure d'une dizaine de ligne dans laquelle figure une boucle, qui elle-même fait appel à la fonction qui vient d'être déterminée.

J'aimerais donc éviter de répéter n fois cette procédure, dont le contenu doit être ajusté en fonction de... la fonction.

Si les paramètres réels sont les mêmes, alors stockes le tout dans un boost::function qui a reçu le résultat d'un boost::bind et le tour est joué.

He non, ils sont différents...

Il semble donc qu'il n'y ait pas de solution.

Si, suivre le pattern command en reprennant le design initial du GOF -- avec boost::function, on arrive à avoir ce pattern également.
Sauf que là, tu prévoies les deux fonctions dans ta hiérarchie de classes de commande, les deux fonctions que tu veux appeler.
Il faut quand même que tu sois capable de spécifier de manière polymorphique les arguments à passer à tes deux fonctions.

Bref, oublie le couple enums-switch et penses objet. Tant que j'y pense, le pattern template method (qui n'a rien à voir avec les templates du C++) me semble également parfaitement adapté.

OK, j'ai le bouquin de GOF à portée de main.

Ca me paraît être un bon exercice pour me mettre aux design patterns.

Merci, je vais essayer le Command Design.