pointer générique de fonction d'une class

Bonsoir a tous amis developers

Google n'ayant put me trouver une réponse, j'appel votre savoir ce soir sur une question très particulière. Actuelement, je travail sur un système de répartition des taches entre des threads. Mais la ou je recontre des soucis, c'est que mon code devient très vite indigeste a cause de l'usage de beaucoup template pour crée des pointers vers des fonctions de class.

Exemple

Code:

---

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

// ------------------ UNE CLASS EN EXEMPLE   class MA_CLASS { [...] };     // ------------------ UN BOU DE CODE   int (MA_CLASS::* maFonction) (); // notez que je suis obligé de precisé la class

---

Ma question est : existe il un moyen de créer un pointer vers une fonction de class sans la spécifié ?

Un truc dans cet esprit :

Code:

---

1 2	int (class::* maFonction) (); // le pointeur est donc indépendant de la class

---

Merci de votre lecture ainsi que de vos réponses éventuelles. :ccool:

Bonsoir,
Je ne pense pas que ce que tu demandes soit possible.
Un type « pointeur sur fonction » a besoin de connaître le type de tous les arguments et le type de retour pour être valide.
Or on peut voir this comme un paramètre des fonctions membres.

En gros, c'est un peu comme si une fonction membre était en fait déclarée comme la seconde ligne :

Code:

---

1 2 3 4 5 6 7

TYPE_RETOUR classe::foo(ARGUMENTS...); TYPE_RETOUR foo(classe *this, ARGUMENTS...);   //********************//   TYPE_RETOUR classe::foo(ARGUMENTS...) const; TYPE_RETOUR foo(classe const *this, ARGUMENTS...);

---

Du coup, lors de l'appel :

Code:

---

1 2 3 4

classe x; x.foo(...);   => foo(&x, ...);

---

Après, tout dépend ce qui te dérange exactement dans le type des pointeurs sur fonction.

Le seul type de pointeur générique que je connaisse, c'est void*.
Transtyper un pointeur vers void* est trivial, mais dans l'autre sens il peut y avoir des précautions à prendre.
Par exemple, « le standard C99 laisse le transtypage depuis void * vers pointeur sur fonction indéfini » (d'après la page de manuel de dlsym).
Je ne sais pas ce qu'il en est pour les standards C++.

Code:

---

1 2 3

void *src = ...; int (*dest)(double); *reinterpret_cast<void **>( &dest ) = src;

---

Autrement, je ne garantis pas ça fonctionne, mis tu peux essayer quelque chose dans le 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 47 48 49 50 51 52

struct PointeurSurFonction {   virtual ~PointeurSurFonction() {}   };     template <class T> class Fonction1 : public PointeurSurFonction {   public: typedef TYPE_RETOUR (T::*fct_type)(ARGS...);   private: fct_type m_fct;   public: Fonction1(fct_type fct) : m_fct(fct) {}   TYPE_RETOUR operator () (T& obj, ARGS... args) const { return (obj.*m_fct)(args...); }   };     template <class T> class Fonction2 : public PointeurSurFonction {   public: typedef TYPE_RETOUR (T::*fct_type)(ARGS...) const;   private: fct_type m_fct;   public: Fonction2(fct_type fct) : m_fct(fct) {}   TYPE_RETOUR operator () (T const& obj, ARGS... args) const { return (obj.*m_fct)(args...); }   };

---

Il te suffit après de ne manipuler que des pointeurs/références sur PointeurSurFonction.


Ou alors tu t'inspires des adaptateurs pour fonction membre existants, si ceux-là ne te conviennent pas.
mem_fun
mem_fun_ref
mem_fun1
mem_fun1_ref

Sinon y'a std::function et bind qui font un joli travail.

Bonsoir,

tout d'abord, merci beaucoup de ton temps de réponse ! Maintenant, j'ai déjà essayé avec des class semblable à celle que tu propose, mais le problème reste aussi le même étant donné que se sont des templates donc le nom de la class doit être spécifié.

considérons deux class différente

Code:

---

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

class CLASS_A { public: int fonction (float * Coords, unsigned int * Indices); };   class CLASS_B { public: int fonction (char * FilePath, unsigned int * Params); };

---

Ces deux fonctions sont d'après le C++ complètement différent au niveau de l'appel, mais pourtant, niveau assembleur, les instructions d'appel seron exactement les mêmes ... Et donc en exemple C++, le compilateur détecte une erreur juste avec un :

Code:

---

int (CLASS_B::* maFonction) (char *, unsigned int *) = reinterpret_cast <int (CLASS_B::*) (char *, unsigned int *)> (&CLASS_A::fonction) ;

---

Dès l'instant ou je peut effectuer cette opération d'une manière ou d'une autre, le problème pourrait être considéré comme résolu.

pas besoin de ces horreurs : bind et function font l'affaire :

http://codepad.org/9ASRgY9n

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

#include <boost/bind.hpp> #include <boost/function.hpp>   class A { public :   int foo( const char* c) { return 1337; } };   class B { public :   int foo( const char* c) { return 4242; } };   int main() { A a; B b;   boost::function<int(const char*)> pfs[2];   pfs[0] = boost::bind( &A::foo, &a, _1); pfs[1] = boost::bind( &B::foo, &b, _1);   std::cout << pfs[0]("lol") << "\n"; std::cout << pfs[1]("lol") << "\n";   }

---

Citation:

---

Envoyé par Joel F

pas besoin de ces horreurs : bind et function font l'affaire :

http://codepad.org/9ASRgY9n

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

#include <boost/bind.hpp> #include <boost/function.hpp>   class A { public :   int foo( const char* c) { return 1337; } };   class B { public :   int foo( const char* c) { return 4242; } };   int main() { A a; B b;   boost::function<int(const char*)> pfs[2];   pfs[0] = boost::bind( &A::foo, &a, _1); pfs[1] = boost::bind( &B::foo, &b, _1);   std::cout << pfs[0]("lol") << "\n"; std::cout << pfs[1]("lol") << "\n";   }

---

---

d'après mes tests, un appel de fonction avec std::function c'est 3 à 4 fois plus cher qu'un foncteur classique, sans compter les couts supplémentaires des placeholders de bind

après tout dépend de l'application évidemment

Bonsoir,

Citation:

---

Envoyé par coda_blank

d'après mes tests, un appel de fonction avec std::function c'est 3 à 4 fois plus cher qu'un foncteur classique, sans compter les couts supplémentaires des placeholders de bind

après tout dépend de l'application évidemment

---

Question : Si ce surcout n'est pas négligeable devant le temps d'exécution du thread, on peut presque se demander quel est l'intérêt de faire un thread non?

Citation:

---

Envoyé par coda_blank

d'après mes tests, un appel de fonction avec std::function c'est 3 à 4 fois plus cher qu'un foncteur classique

---

j'ai jamais dit le contraire. mais wowow passer de 2 cycles a 8 ne m'inquiete guere.

Citation:

---

Envoyé par coda_blank

sans compter les couts supplémentaires des placeholders de bind

---

la tu diverge, _n n'ont aucun surcout

Bonsoir

L'utilisation de boost est bien sympathique, plus propre même ! :mouarf: Mes taches sont relativement longue donc l'appel d'une fonction boost est largement admissible ... Mais j'ai aussi un très grand nombre de taches à exécuter. Etant donné que j'ai des algorithmes qui tri les taches dans un ordre bien précis avec prise en compte d'héritage, filtres par threads (pour utilisation de bibliothèque non thread-safe comme OpenGL) et compagnies ... Donc l'utilisation d'une bibliothèque haut niveau comme boost peut me faire perdre en performance la dessus.

Bien que boost soit plus simple pour cette utilisation, je compte néanmoins travailler en bas niveau car c'est ensuite l'utilisation de mes objets qui me rendra les choses encore plus simples, mais avec plus de performance que si j'utilisais boost. J'ai fournis un assez gros travail pour utiliser les compteurs atomiques et autres instructions du genre, se serais dommages de perdre donc le gain par boost. :)

actuellement j'arrive à un rendement de de 91% sur un 12 coeurs (donc 12 threads) qui est l'un de mes records, d'ou mon souhait que la programmation reste bas niveau.

Je suis en train de voir pour programmer directement le cast de pointeurs de fonctions en assembleur dans le C++, à mes risques et péril. (çà devrai pas être plus compliqué que les pointers "normaux" :mrgreen:)

Je vous tiens au courant .... ;)

Citation:

---

Envoyé par LastSpear

Bonsoir

L'utilisation de boost est bien sympathique, plus propre même ! :mouarf: Mes taches sont relativement longue donc l'appel d'une fonction boost est largement admissible ... Mais j'ai aussi un très grand nombre de taches à exécuter. Etant donné que j'ai des algorithmes qui tri les taches dans un ordre bien précis avec prise en compte d'héritage, filtres par threads (pour utilisation de bibliothèque non thread-safe comme OpenGL) et compagnies ... Donc l'utilisation d'une bibliothèque haut niveau comme boost peut me faire perdre en performance la dessus.

Bien que boost soit plus simple pour cette utilisation, je compte néanmoins travailler en bas niveau car c'est ensuite l'utilisation de mes objets qui me rendra les choses encore plus simples, mais avec plus de performance que si j'utilisais boost. J'ai fournis un assez gros travail pour utiliser les compteurs atomiques et autres instructions du genre, se serais dommages de perdre donc le gain par boost. :)

actuellement j'arrive à un rendement de de 91% sur un 12 coeurs (donc 12 threads) qui est l'un de mes records, d'ou mon souhait que la programmation reste bas niveau.

Je suis en train de voir pour programmer directement le cast de pointeurs de fonctions en assembleur dans le C++, à mes risques et péril. (çà devrai pas être plus compliqué que les pointers "normaux" :mrgreen:)

Je vous tiens au courant .... ;)

---

Bas niveau, haut niveau, ça ne veut rien dire.
Peux-tu démontrer que l'utilisation de std/tr1/boost::bind et std/tr1/boost::function est une source de coût non négligeable dans le contexte de ton appel par rapport à une bidouille immaintenable, illisible, importable et probablement source de bug ?

Ce que tu sembles vouloir faire, si j'ai bien compris (on me corrigera si je dis des bêtises) est un Type Erasure. Je conseille de lire le chapitre 9.7 du Abrahams.

Pour std/boost::function, je connais pas le surcoût (et s'il y en a un). Par contre, tu peux utiliser aussi ptr_fun/mem_fun/mem_fun_ref qui n'ont pas de surcoût à l'exécution (voir Effective STL, Meyers, item 41)

Bonsoir,

tout d'abord,

Citation:

---

Bas niveau, haut niveau, ça ne veut rien dire.

---

Ce n'est pas la première fois que l'on me fait cette remarque. C'est vrai que c'est discutable parmi les developers. Pour certains, çà ne veux rien dire. Néanmoins çà ne signifie pas que cela ne veux rien dire en règle absolue. Après j'ai appris la programmation dans un entourage qui se sert de cette expression, qu'il en soit ainsi. J'ai oublié que certain pouvait être contre cet emploi, ainsi je vous présente mes excuses.

Pour en revenir à nos moutons, j'ai donc tester en modifiant de deux manière mon gestionnaire de taches, l'une avec la bibliothèque boost, l'autre avec le cast des pointeurs de fonction par instructions assembleur (mis dans une incline pour conservé la lisibilité). D'ou le retard de réponse.

J'ai donc fait quelques benchmark plus poussé pour comparé les deux solution et ainsi je vous le fais partagé :

- Point de vu performance:
Lors de l'appel des fonctions, la différence est totalement négligeable la dessus, aucune surprise. Par contre, pendant le processus de répartition, qui reparti, tri, déplace, donc copie ces pointers à tout bout de champ, je note une perte de performance avec l'utilisation boost qui est l'ordre de 7% plus lent que son rival en assembleur. Ce qui m'amène à un rendement d'exécution de 8 coeurs de 91.3% à 90.4%. Oui bon d'acore, c'est pas bien énorme, je vous l'accorde. Mais dans le contexte dans lequel je doit le faire, c'est a dire une petite compétition pour l'algorithme le plus performant, laissé moi vous dire que j'opte pour la solution sans boost. Néamoin,

- Point de vu codage:
il n'y a pas photo, l'utilisation de boost rend carrément plus lisible le code même si j'estime avoir fait de mon mieux pour l'assembleur à coup d'inlines. J'avoue que la solution pour boost, que j'ai programmer en premier, a été beaucoup plus rapide. Oui la solution en assembleur est pas portable, mais elle se compile sous Linux (gcc), Mac OS (gcc) et Windows (visual studio). Etant donné que j'utilise des inlines, sufis seulement de mettre quelque #ifdef et le tour est joué. Je peut programmé sur les trois plate-forme en toute transparence.

Aussi, je me suis intéressé à ptr_fun/mem_fun/mem_fun_ref, qui semble faire à peut près la même chose que ma solution en assembleur, mais je me suis aussi dit : qui-t-a faire plus compliqué, au temps le faire soit même. Résultat: 0 bugs, le sentiment d'avoir une connaissance plus accru sur la question, et la conviction que çà n'a pas été une perte de temps de faire cette comparaison.

Maintenant, mon système utilise plus aucuns templates, donc l'écriture de mon code qui utilise mes class est donc plus digeste. Ainsi l'objectif premier de ma question est résolu et sera probablement un bon argument suplémentaire au moment de comparaison des solutions.

Désolé de n'être plus précis pour l'instant sur le fonctionnement de mon système, je sais que certain de mes concurrent direct sont aussi sur ce forum.;)

Merci beaucoup de votre temps et de vos conseils, ils ont été très fructueux. :ccool:

Citation:

---

Envoyé par LastSpear

Ce n'est pas la première fois que l'on me fait cette remarque. C'est vrai que c'est discutable parmi les developers. Pour certains, çà ne veux rien dire. Néanmoins çà ne signifie pas que cela ne veux rien dire en règle absolue. Après j'ai appris la programmation dans un entourage qui se sert de cette expression, qu'il en soit ainsi. J'ai oublié que certain pouvait être contre cet emploi, ainsi je vous présente mes excuses.

---

J'aurais pas forcement dit que cela ne veut rien dire. Plutôt que cela veut tout dire et rien dire : chacun met un peu à sa sauce le bas niveau/haut niveau, en général pour argumenter dans son sens. Bref, cela ne veut rien dire si on précise pas le contexte.

Citation:

---

Envoyé par LastSpear

Pour en revenir à nos moutons, j'ai donc tester ...

---

Tu as oublié de testé la maintenabilité et l'évolutivité des différentes approches. Personnellement, j'arrive pas à écrire une ligne de code sur laquelle je serai jamais obligé de revenir au moins une fois dessus pour la corriger ou faire évoluer.
A la rigueur sur un petit projet, qui dure pas dans le temps (mais cela veut dire que l'on pourra récupérer moins facilement le code pour un plus gros projet) et sur lequel je travaille seul, ça pourrait aller (bien que cela m'aidera pas à apprendre les bonnes pratiques de programmation). Par contre, sur un projet qui est successible d'avoir des bugs (ce qui arrive jamais... :aie:), d'évoluer, de devenir gros, d'avoir une équipe dessus (imagine s'il faut que toute l'équipe maîtrise le C++ et l'asm sur différentes plateformes, dur dur)
A priori, comme c'est pour une compétition de performance, ça pourrait être acceptable... mais à oublier très vite comme approche :)

y a qqpart dans le boost vault une imple de function avec un trampoline en assembleur, a voir donc si tu pourrais pas avoir le beurre et l'argent du beurre.

Citation:

---

Personnellement, j'arrive pas à écrire une ligne de code sur laquelle je serai jamais obligé de revenir au moins une fois dessus pour la corriger ou faire évoluer.

---

Je pense qu'il serait de mauvais gout qu'un développeur affirme le contraire. :ccool:
Même si je ne suis encore que dans ma genèse niveau conception d'algorithme, j'ai néant moins quelque méthodes qui me permette d'évité au maximum se souci. Personnellement, j'ai compris de mon expérience (encore très jeune) que la modifications et évolution de systèmes est une grande source de bugs. Donc j'essai plutôt de concevoir un système le plus complet possible, bien testé et optimisé pour qu'il ai une duré de vie la plus longue possible dans d'autres projets. En autre je n'ai pas encore fini de concevoir mon système actuel, il risque encore de bien évolué dans les prochaines semaines. Ainsi je ne m'intéresse pas à la maintenabilité de chacun de mes systèmes car de toute façon si je revient dessus, ce sera pour un refaire un nouveau en prenant compte les faiblesse des versions précédente. :mouarf: Je ne cache d'ailleur pas que certains systèmes on même été ré-écrit une bonne dizaine de fois. :oops: Alors la quantité de travail nécessaire est serte plus conséquente, mais la qualité est elle inéluctablement bien meilleurs qu'avant.

Evidament, je programme très rarement en equipe, et je te rejoint sur le faite que ce genre de solution exotique est a évité. ;) Mais il m'est déjà arrivé qu'en équipe, on ai réutilisé certains de mes algorithmes probablement grasse à leurs stabilité, car jamais réédité. De plus je ne cache pas que certains de ces algorithmes utilisent des solutions exotiques, mais si celles ci restent encapsulés, mes collègue on pas besoin de comprendre le le code source derrière la documentation.