Reprise du message précédent :
c'est pas ça du tout. les fonctions membres non-static ne sont tout simplement pas des fonctions comme les autres fonctions libres. Si y avait que cette histoire de this implicite, on se marrerait bien.

oui mais le sujet de ce topic consiste justement à expliquer comment contourner le this implicite, le reste est HS

si t'avais vu un peu le code de chrisbk, tu verrais que la principale difficulté, c'est de récupérer le pointeur de la fonction membre et d'invoquer tout le fatras correctement

 
bah c chiant a recuperer parce que les compilos bloquent au niveau du type. Invoquer le fatras ca va, la seule blague c'est de passer le param 'this' supplémentaire, justement

g compris l'explication d'Harko...

Quand j'ai vu ce post, je me suis dis : chouette, je vais enfin savoir ce que les gens entendent par delegate. Je commence à lire et je dis "Quoi ? C'est tout ? Et c'est quoi ce hack pour faire marche ce truc si simple en plus ?"
 
En fait, les delegate, c'est juste une façon compliquée de nommer des bound methods. Et je ne parle même pas de la currification des fonctions dans les langages fonctionnels qui permet de faire tout ça en bien plus encore.
 
Une raison sur le pourquoi de ce changement de nom ? Ou alors c'est le terme "bound method" qui arrivé en deuxième peut-être ?

nraynaud sors de kristoph

ben parce que c'est pas dans C++. Pour faire ça, on a STL et boost qui font des trucs nickel. En C#, on a des delegate pour pas avoir à se taper des interfaces à la con dans tous les sens. Appelle ça comme tu veux, mais c'est clair que ça vaut pas les truc simplissimes où 'obj.method' est effectivement un objet à par entière

La currification, il n'y a que ça de vrai pour les langages statiquement typés. D'ailleurs, je viens de voir boost::bind et c'est vraiment très bien ce truc. Dommage que la syntaxe fasse "hack" mais bon c'est surement le mieux qu'ils pouvaient faire sans changer le langage.

yep. boost:: bind, function, lambda and signals sont vraiment chouettes

Réflexion faite, ma curiosité est devenue du scepticisme. Pour ce que j'en ai vu, boost::function est un foncteur un peu sofistiqué, donc en gros c'est l'opérateur () qui fait le boulot. Qui dit opérateur dit fonction membre, donc pointeur this. Or le sujet de ce débat est qu'on peut pas passer ça à une callback C...
Donc aux chiottes boost::function
 
Quant à l'histoire delegate <=> currification, c'est pas un renommage. Delegate c'est un pricipe, un Design Pattern même il me semble. Après qu'il soit mis en place via la currification ou les templates, c'est autre chose.

soPHistiqué
 
Sinon hein, t'as vu, y lisent rien au post initial et ca vient faire les cacous avec des trucs qui n'ont rien a voir

ça existe le design pattern 'j'ai pas de pointeur de fonction ni de méthode liée, alors j'émule' ?

C'est comme le Singleton ou le VirtualStatic: c'est pas un Design Pattern, c'est un idiome.

 
C'est un cas particulier de currification avec un nouveau nom pour faire plaisir aux fans d'objet et pour leur faire croire qu'ils ont inventé un nouveau concept génial

 
De toute façon, le terme même de design pattern est volontairement flou, ça pourrait signifier grossièrement "technique de programmation". Il y a quantité de design patterns qui ne sont là que pour pallier à des déficiences de langage, et qui n'ont pas lieu d'exister dans d'autres langages.

Oui.
Un DP, c'est la solution à un problème donné, avec un nom, une suggestion d'implémentation, et les conditions d'utilisations/limites du système proposé.  
 
Un DP peut donc être un idiome (exemple: Singleton), un ensemble de classes (Composite), ou un ensemble de DP (MVC).
 
Mais si ton problème n'est pas spécialement particulier, s'il ne s'applique qu'à un seul langage, et s'il n'y a pas de réél cas où il faut l'utiliser ou s'en passer (pas d'antipatterns), il y a des chances pour que ce ne soit pas un DP très intéressant: juste un bon idiome.  
 
Le Delegate Colgate est très bien, mais ce n'est pas franchement un DP qui va révolutionner le monde.
 
C'est comme ça que je vois les choses en tout cas.

 
Plusieurs choses/questions :
1) HA. Je n'étais conscient que du pb du ptr this.
Il y a quoi comme autres pbs que le pointeur this ?
 
2) je connaissais que la solution proposée par Harkonnen (Dans une classe wrapper, faire une méthode static, conserver le ptr this, passer la méthode static a la callback, appeler la vraie callback dans la methode static) ou encore l'emploi de la lib boost::function (que je n'ai jamais utilisée dans ce contexte. D'ailleurs, c'est facile  
à utiliser ?).
Merci de proposer cette autre solution, que je trouve assez couillue

d'abord c'est la méthode de personne le coup du static. Et Harko est arrivé comme un cheveux sur la soupe. Utilise boost::function. Je sais pas ce que tu trouve couillu, mais du dois être sacrément poilu de la paume pour ne pas avoir été lire la documentation/tutoriel/exemple de boost.

Oué bon on va laisser tomber, hein ?

Nan, y'a Joel F qui bosse encore dessus.

on attends tjs son bout de code
Mais la je sens qu'on va tourner en rond, avec boost si, boost ca, mais j'ai tjs pas vu de code qui bindait une fonction membre sur une vieille callback C pourrie. Pis crotte, quoi, voir meme, maÿrde

C'est qu'il bosse tard le bonhome.

 
Bon, ok, je l'avoue, je m'attendais a cetet réaction... Tu n'es plus drole Taz, t'es trop prévisible
Accéssoirement, j'aurais bien aimé que tu répondes a ma première question.
 
Quant à la question sur boost, non, j'ai pas lu la doc, je te demande un avis perso. Facile a utiliser, des choses a savoir de particulier, conseils d'utilisations ? Je ne lis la doc que si je m'apprete a l'utiliser, et je choisirais en fonction (en partie) de tes remarques a ce sujet, si tu veux bien en formuler. Je n'ai plus de temps a perdre a eplucher des API pour le dev perso.
 
Ne sois pas jaloux non plus, harkonnen a donné en premier la methode que j'utilise depuis qques temps, j'ai pas dit que c'etait la sienne, hein...
 
Edit : ha oui, ce que je trouve "couillu", c'est l'idée d'utiliser une structure pour placer des instructions de sauts vers une autre portion de code. Je m'incline devant celui qui a eu le premier cette idée (qui n'est pas parmi nous), car perso, je n'y aurais pas pensé.  

En vrac parce que moi je bosse
 
http://www.crystalclearsoftware.co [...] _Callbacks

Ouais enfin, du code C-style, j'en fait en Java aussi, hein. Ca n'en fait pas du code appellable depuis le C pour autant.

exact

Ca nous explique comment faire des callback dans un esprit plus C++ boost, mais pas comment refiler notre fonction membre en tant que fonction callback C.

 
Justement, je me demandais : c'est lequel le meilleur langage de programmation ?
 
 
 
 
 
 
 
 
 
 
 
 
 

Je vois bien une solution avec un pool de fonctions callback génériques et un allocateur mais ça ne scale pas très bien

ce qui est bien c'est que t'as vachement bien assimilé le moment où on a dit 'si y avait un void* data a filé au callback, y aurait aucun problème'

quoi encore ?

Jcrois qu'il est dans une mauvaise passe le Taz, d'hab' il me rapelle un caillou dans la chaussure mais la ca tiens plus de la gastro carabinée

Alors attention ça va faire mal. Il fallait bien 2 jours pour la trouver celle là.
Ton delegate, il permet d'appeler des fonctions membres de classes n'est-ce pas ? Peut-on dire qu'il s'agit d'un delegate de class ?

heuh

OMFG IWHBATW

je sais pas je comprends rien : y a la moitié des personnes ici qui parle de fonction static et de créer un callback void (*)(void *) et l'autre qui est coincé par qu'ils ont des fonctions membres et des void (*)() ...

 
moi j'ai rien dit

bah t'es dans la première catégorie

ben tant pis, j'ai jamais rien utilisé d'autre que boost::function alors tu sais

bah moi pareil. Les cb C mal foutus, ça pue. Mais je vomis également les API C et leur void* ça fout tout le typage en l'air, surtout quand dans le dit void* y a un int ... gtk+ Surtout que grâce à ces callback à la con, zéro inlining : même pour enculer une mouche avec un g_array_foreach ... c'est à pleurer

 
Humour overload.