Discussion :

[diesel83]

Bonjour,

Juste une petite question :

Je cherche à comprendre l'intérêt d'une syntaxe rencontrée dans certains programmes avec l'utilisation de (void).

Dans un programme téléchargé sur internet, à l'intérieur d'une fonction recevant, par exemple trois paramètres (a priori des pointeurs), deux d'entre eux ne sont pas utilisés dans la fonction et le programmeur a rédigé un code ressemblant à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
void fonction tartempion (int *p_int, double *p_double, char *p_char)
 
{
 
     printf ("%f\n", *p_double);
 
    (void) p_int;
    (void) p_char;
 
}

Qui peut me dire quel est l'intérêt des deux lignes avec le cast (void) ?

Merci d'avance.

Jean-Marie

[gangsoleil]

Bonjour,

Une explication possible : la fonction a un prototype fixe, qui ne peut pas être changé (par exemple une fonction d'une librairie ouverte à l'extérieur, une fonction que tu passes en paramètre à une autre fonction, ...). Dans ce cas, avec gcc au moins, tu vas avoir un warning à la compilation quant au fait que tes paramètres ne sont pas utilisés.

Donc si tu veux supprimer ce warning, tu peux utiliser les paramètres de façon à ce que le programme ne plante pas quelle que soit leur valeur.

[diesel83]

Bonjour,

Une explication possible : la fonction a un prototype fixe, qui ne peut pas être changé (par exemple une fonction d'une librairie ouverte à l'extérieur, une fonction que tu passes en paramètre à une autre fonction, ...). Dans ce cas, avec gcc au moins, tu vas avoir un warning à la compilation quant au fait que tes paramètres ne sont pas utilisés.

Donc si tu veux supprimer ce warning, tu peux utiliser les paramètres de façon à ce que le programme ne plante pas quelle que soit leur valeur.

Merci pour la réponse.

Je crois que c'est effectivement la bonne raison (en tous cas, je n'arrive pas à en imaginer d'autre).

De plus, au delà de ne pas faire râler gcc, cela permet aussi d'améliorer la lisibilité du code en affichant "en clair" que le paramètre n'est pas utilisé par la fonction (pour le cas qui m'occupe en ce moment, il s'agit de la bibliothèque GTK+).

Le sujet est résolu en ce qui me concerne.

Jean-Marie

[picodev]

Bonjour,

comme le dit GangSoleil, c'est une syntaxe pour dire au compilateur «j'utilise ce paramètre pour ne rien en faire, juste pour que tu ne me donnes pas de warning».

Personnellement je ne trouve pas cette pratique recommandable. L'obsession du «la compilation ne doit faire apparaître aucun warning» est amha vaine et parfois dangereuse.

Les alternatives pour éviter ces warnings sont avec gcc et clang d'utiliser les attributs de variables. Un autre moyen plus efficace à mon avis est d'utiliser les pragmas de type message pour avertir lors de la compilation que certains warnings sont «attendus, connus et documentés dans le code».

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
int test1 (int a, int b);
int test2 (int a, int b);
 
int test1 ( __attribute__ ((__unused__)) int a, int b) {
  return 2*b;
}
 
int test2 (int a, int b) {
  return 2*b;
#pragma message "Le paramètre a n'est pas utilisé dans test2 ... blabla"
}
 
int main (void) {
  test1(1,2);
  test2(1,2);
 
  return 0;
}

Si tu compiles ce code avec gcc, tu obtiendras :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$ gcc -o void void.c -Wall -Wextra
void.c: In function ‘test2’:
void.c:10:9: note: #pragma message: Le paramètre a n'est pas utilisé dans test2 ... blabla
 #pragma message "Le paramètre a n'est pas utilisé dans test2 ... blabla"
         ^
void.c:8:16: warning: unused parameter ‘a’ [-Wunused-parameter]
 int test2 (int a, int b) {

Aucun warning sur test1 car on a précisé que le paramètre pourrait être non utilisé. Un warning pour le paramètre non utilisé dans test2 et en tout début le message issu du pragma qui explique le warning.

La syntaxe (void) parametre; a cependant l'avantage d'être reconnue par tous les compilateurs.

[Bktero]

@gangsoleil : +1


@picodev: je trouve la technique du #pragma message totalement hideuse. Pourquoi polluer la sortie du compilateur avec un message qui ne sert à rien à part documenter un autre message qui ne sert à rien non plus !?
La technique de l'attribut est plus élégante en effet, dommage pour sa portabilité.

[picodev]

@picodev: je trouve la technique du #pragma message totalement hideuse. Pourquoi polluer la sortie du compilateur avec un message qui ne sert à rien à part documenter un autre message qui ne sert à rien non plus !?
La technique de l'attribut est plus élégante en effet, dommage pour sa portabilité.

En effet, c'est moche. Je ne la citais que comme alternative si on voulait faire quelque chose de warnings que l'on peut trouver indésirables. Cacher n'est à mon avis jamais une bonne chose.
Personnellement je préfère laisser les warnings que de demander au compilateur de ne pas les afficher. L'attribut est élégant mais le seul reproche que je pourrais faire est de ne produire aucun warning si un paramètre déclaré comme non utilisé l'est effectivement.

[diesel83]

Une des solutions pourrait être d'entourer les lignes (void) symbole; par une directive :

#IFDEF NO_WARNING_UNUSED
#ENDIF

et de définir NO_WARNING_UNUSED à la compilation.

De plus, le besoin d'utiliser ces déclarations semble limité à des fonctions de callback liées à des bibliothèques d'interfaces dynamiques (GTK+ par exemple) dans lesquelles c'est un objet de la bibliothèque qui fixe "arbitrairement" les paramètres passés à la fonction de callback (qu'il ne connait pas a priori) et dont la fonction de callback n'a pas forcement besoin.

Dans du code écrit pour un projet donné dans lequel on trouve à la fois les fonctions et les appels à ces fonctions, il suffit (et je dirais même "il est indispensable") de déclarer le bon nombre de paramètres de chaque côté.

Enfin, je pense qu'il est plus judicieux de mettre ces déclarations juste derrière le crochet ouvrant avec un bon commentaire.

Jean-Marie

[gangsoleil]

le besoin d'utiliser ces déclarations semble limité à des fonctions de callback liées à des bibliothèques d'interfaces dynamiques (GTK+ par exemple)

Dans Posix, il y a souvent ce genre de code lors de l'utilisation des fonctions sur les signaux et sur les threads.

[Obsidian]

De plus, le besoin d'utiliser ces déclarations semble limité à des fonctions de callback liées à des bibliothèques d'interfaces dynamiques (GTK+ par exemple) dans lesquelles c'est un objet de la bibliothèque qui fixe "arbitrairement" les paramètres passés à la fonction de callback (qu'il ne connait pas a priori) et dont la fonction de callback n'a pas forcement besoin.

Dans Posix, il y a souvent ce genre de code lors de l'utilisation des fonctions sur les signaux et sur les threads.

Plus généralement, on va rencontrer ce cas chaque fois qu'une interface est définie à l'avance, donc pour communiquer entre deux systèmes distincts, à commencer par le système d'exploitation et le programme à exécuter. Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
#include <stdio.h>
 
int main (int argc, char **argv)
{
    printf ("Vous avez passé en tout %d paramètres sur la ligne de commande.\n",argc);
    return 0;
}

Ce simple bloc suffit pour être concerné.