dans ce cas c'est exact, mais on peut toujours s'arranger avec une structure..
Ceci dit je suis d'accord que ce ne sont pas des paramètres "utilisateurs", mais le fait quand même que ce soit générique est pas si mal, non ??
Il est un tant soit peu diffcile de fournir une bibliothèque permettant d'accepter une routine inconnue sans en préciser l'API..
Là, on a bien un void* que l'on trie, quand même...
Bon, lles vraies callbacks incluent un void* pour le data utilisateur..
Mais dans le cas d'une callback DANS un algo prédéterminé avec une fonction déterminée, la situation me semble totalement suffisante...
Maintenant, pour le problème du PO, cela peut se faire : il suffit de définir un type de fonction et un type de paramètre, avec un type de "structure" retour principale..
Ce qui se fait dans toutes les biblothèques graphiques...
OnClick ( Widget w, OnClickStruct *ActionStruct, void *ClientData )
On définit un type de fonction void, (ou int, ou ce qu'on veut) ayant 3 (ou 2) paramètres dont 1 void.
Le 2ième paramètre (ou le premier) sert à communiquer ce que peut communiquer ce type d'algo , d'objet, etc (sur un bouton, ce sera l'état par exemple, plus un flag si c'est un double clic ou non).. Le 3ième (ou second) sert juste à faire retourner à la routine faite par l'utilisateur ses propres données, sans interprétation du tout...
Partager