typedef void (*HANDLER)(void);

Version imprimable

07/04/2016, 09h27
pascal_06

typedef void (*HANDLER)(void);

Bonjour à toutes et à tous,
J'ai trouvé cette expression dans le header d'un programme en C sur microcontroleur :

Code:

typedef void (*HANDLER)(void);

.
Par la suite, c'est utilisé, par exemple, dans le code de la manière suivante :

Code:

int uneFonction (HANDLER unHandle) { ...}

J'aimerais comprendre le fonctionnement de cette expression en C car je n'ai trouvé aucune explication en français, ni aucune explication compréhensible en anglais.
J'aimerais, si possible, trouver des exemple d'utilisation simple de ceci.
Je vous remercie par avance !

Salut,

il s'agit d'un type personnalisé (typedef) décrivant un pointeur de fonction ((*HANDLER)) dont l'emprunte nous dit que la fonction pointée ne doit rien renvoyer (void) et ne prendre aucun argument ((void)). Un exemple rapide (et un peu pourri) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 typedef void (*HANDLER)(void); void hello_en(void) { printf("Hello !\n"); } void goodbye_en(void) { printf("Goodbye !\n"); } void hello_fr(void) { printf("Bonjour !\n"); } void goodbye_fr(void) { printf("Au revoir !\n"); } void bePolite(HANDLER hello, HANDLER goodbye) { hello(); goodbye(); } int main(int argc, char *argv[], char* envp[]) { bePolite(hello_en, goodbye_en); bePolite(hello_fr, goodbye_fr); return 0; }
Résultat sur la sortie standard :
Code:

1 2 3 4 Hello ! Goodbye ! Bonjour ! Au revoir !

07/04/2016, 10h53
Médinoc

D'ailleurs, un typedef de pointeur de fonction sans paramètre est déconseillé, car il ne permet pas de passer un contexte à la fonction sans passer par une variable globale. Même si, pour de l'embarqué, ça peut être excusable.

Citation:

Envoyé par jopopmk

Du code ...

Mais cela reste des pointeurs ;) ;)

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
typedef void (*HANDLER)(void);
 
void default_hello(void)   { printf("nuqneH !\n"); }
void default_goodbye(void) { printf("Qapla' !\n"); }
 
void hello_en(void)   { printf("Hello !\n"); }
void goodbye_en(void) { printf("Goodbye !\n"); }
 
void hello_fr(void)   { printf("Bonjour !\n"); }
void goodbye_fr(void) { printf("Au revoir !\n"); }
 
void bePolite(HANDLER hello, HANDLER goodbye) {
     if (hello != NULL) {
          hello();
     } else {
          default_hello();
     }
 
     if (goodbye != NULL) {
          goodbye();
     } else {
          default_goodbye();
     }
}
 
int main(int /*argc*/, char */*argv*/[], char* /*envp*/[]) {
     bePolite(hello_en, goodbye_en);
     bePolite(NULL, NULL);
     bePolite(hello_fr, goodbye_fr);
 
     return 0;
}

Édit: D'ailleurs j'hésite toujours :wow: entre la syntaxe bePolite(hello_en, goodbye_en); et bePolite(&hello_en, &goodbye_en); (<- avec l'opérateur adresse &).

07/04/2016, 12h02
jopopmk

Pour ma défense j'avais dit qu'il était un peu pourri mon code :mrgreen:
Pour le main c'est un snip VS.
07/04/2016, 23h09
Bktero

Tout n'est pas programmation défensive dans la vie ! Ces tests ne sont pas obligatoires, il ne montre qu'une certaine approche du contrat entre la fonction et ses appelants.
08/04/2016, 21h40
jopopmk

Citation:

Envoyé par Bktero

Tout n'est pas programmation défensive dans la vie ! Ces tests ne sont pas obligatoires, il ne montre qu'une certaine approche du contrat entre la fonction et ses appelants.

Petit HS : ça fait penser à la cellule qualité au taff à qui on doit expliquer que les fonctions statiques ne doivent pas être blindées, qu'il n'y a pas réellement de tests unitaires complets possibles, qu'elles font parti d'un tout, avec un périmètre fonctionnel bien délimité. Après, tester deux pointeurs non nuls n'est pas nécessairement la mort, le check du flag zéro est pas très coûteux en soi. Fin du HS.

Ce que j'aimerais c'est que pascal_06 comprenne le principe du callback qui est très puissant à mon sens, ça ouvre des perspectives conceptuelles assez géniales.
09/04/2016, 00h18
Médinoc

Citation:

les fonctions statiques ne doivent pas être blindées

Je comprends le raisonnement, mais je trouve que c'est le parfait endroit pour utiliser non pas du vrai code blindant, mais des assertions. Pour voir immédiatement, dans la build Debug, que l'appelant a fait une connerie.
11/04/2016, 15h20
pascal_06

Bonjour à tous,
je vous remercie pour vos réponses très instructives !
Je comprend un peu mieux maintenant, à moi de manipuler un peu ce concept...

Citation:

Envoyé par foetus

Mais cela reste des pointeurs ;) ;)
Édit: D'ailleurs j'hésite toujours :wow: entre la syntaxe bePolite(hello_en, goodbye_en); et bePolite(&hello_en, &goodbye_en); (<- avec l'opérateur adresse &).

Oui, tiens, c'est vrai, pourquoi ne pas mettre l'opérateur & ?
Si on ne le met pas, est ce que ça veut dire qu'on passe par "valeur" (????) la fonction toute entière (excusez moi si ce que j'écris des inepties !)
;)
11/04/2016, 16h49
Médinoc

Disons que pour les pointeurs de fonction, il y a une certaine "liberté" et je ne sais pas trop à quoi elle est due. La même chose s'applique aux appels, d'ailleurs (on peut aussi bien faire pf(x) que (*pf)(x)).

Par contre, c'est un peu plus strict en C++ dans certains cas.

Bonjour,

La norme indique :

Au paragraphe 6.3.2.1 section 4

Citation:

A function designator is an expression that has function type. Except when it is the operand of the sizeof operator or the unary & operator, a function designator with type ‘‘function returning type’’ is converted to an expression that has type ‘‘pointer to function returning type’’.

Donc printf est un pointeur.
Au paragraphe 6.5.3.2 sections 1 à 4

Citation:

1. The operand of the unary & operator shall be either a function designator, the result of a
[] or unary * operator, or an lvalue that designates an object that is not a bit-field and is
not declared with the register storage-class specifier.
2 The operand of the unary * operator shall have pointer type.

On a le droit d'utiliser les opérateurs & et * sur un désignateur de fonction.

Citation:

3. The unary & operator yields the address [...] Otherwise, the result is
a pointer to the object or function designated by its operand.

En gros le & sur une fonction ne change rien.

Citation:

The unary * operator denotes indirection. If the operand points to a function, the result is
a function designator;

Idem pour le *.

Du coup le parenthésage est important aussi. Par exemple si on définit une macro avec le même nom qu'une fonction le fait de parenthéser fait que l'identifiant sera reconnu comme une fonction.

On peut résumer tout ça dans ce code (vite fait …) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #include <stdio.h> void test(int a) { (void) a; puts("test function"); } #define test(a) puts("test macro") int main(void) { printf(" printf = %p\n", printf); printf("&printf = %p\n", &printf); printf("*printf = %p\n", *printf); test(10); (test)(10); return 0; }
qui donne à l'exécution :
Code:

1 2 3 4 5 6 $ ./func printf = 0x400450 &printf = 0x400450 *printf = 0x400450 test macro test function