Discussion :

[Thierry Chappuis]

Bonjour à tous,

Je viens ici avec un sujet un peu général, au sujet duquel votre avis m'intéresse. J'ai lu dans un post sur le groupe usenet comp.lang.c qu'il fallait le plus possible limiter l'utilisation du préprocesseur C. Qu'en pensez-vous?

Je pense que le problème majeur vient de la lisibilité du code, car on peut écrire:

Code :

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

1
2
3
4
 
#if defined(UNE_MACRO)
/*...un bout de code ...*/
#endif

On peut alors définir UNE_MACRO à la compilation:

Code :

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

gcc -DUNE_MACRO -c -o monfichier.o monfichier.c

Et là c'est une horreur de suivre le chemin d'exécution du code, lorsque la taille du projet devient importante.

En revanche, pour toute macro définie dans un fichier d'entête, je ne vois pas (avec mes yeux de débutant) pourquoi l'usage du préprocesseur ne serait-elle pas conseillée:

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
19
20
21
22
23
24
25
/* entete.h */
#ifndef H_TC_ENTETE_20061109111233
#define H_TC_ENTETE_20061109111233
 
#define UNE_MACRO
 
#endif /* guard */
 
/* main.c*/
#include <stdio.h>
#include <stdlib.h>
#include "entete.h"
 
int main(void)
{
    #ifdef UNE_MACRO
    printf("SUper, UNE_MACRO est définie!\n");
    #endif
 
    #ifndef UNE_AUTRE_MACRO
    printf("Eh oui, UNE_AUTRE_MACRO n'est pas définie!\n");
    #endif
 
    return EXIT_SUCCESS;
}

Suivre l'exécution de ce code ne pose pas de problème particulier, comme d'ailleur l'utilisation de MACRO définies dans la bibliothèque standard. Où est donc le problème avec le préprocesseur? J'attend vos commentaires et retour d'expérience avec beaucoup d'intérêt. Faut-il préférer l'utilisation de fonction inline (C99) plutôt que l'usage de macros? Beaucoup de programmeurs hésitent encore à utiliser C99 pour des questions de portabilité.

Meilleures salutations et merci pour tout

Thierry

[DaZumba]

Tu melanges un peu deux choses : compilation conditionnelle et macros pouvant etre remplacees par des fonctions inline.

[Thierry Chappuis]

Alors, sortons la compilation conditionnelle qui un cas particulier de l'utilisation du préprocesseur C et concentrons-nous sur l'usage de ce même préprocesseur pour définir des macros uniquement. En quoi est-il préférable d'utiliser une fonction inline plutôt qu'une macro? La spécification des directives du préprocesseur C fait partie de la norme et donc, en principe, la définition de macros ne présente aucun problème de portabilité est encore moins de performance.

Je pense à deux aspects en faveur des fonctions inline C99:

- Le compilateur a le choix de ne pas rendre la fonction inline si le corps de cette dernière est trop long (trop d'instructions). Il s'agit donc d'une question je présume d'optimisation de la taille de l'exécutable.
- L'écriture d'une macro dans les règles de l'art demande quelques précautions:
exemple:

Code :

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

1
2
3
4
5
#define MUL(x, y) (x*y) /* MUL(3+5, 4) sera traduit par 3 + 5 * 3 */
 
alors que
 
#define MUL(x, y) ( (x) * (y) ) /* protège contre ce genre de mésaventures source de bugs */

Est-ce pour cette raison qu'on déconseille d'usage du préprocesseur, parce que l'écriture de fonctions inline permet de s'affranchir de ce genre de problèmes?

Merci

[Emmanuel Delahaye]

Est-ce pour cette raison qu'on déconseille d'usage du préprocesseur, parce que l'écriture de fonctions inline permet de s'affranchir de ce genre de problèmes?

L'argument principal contre les macros est :

"Si une macro évalue un paramètre plus d'une fois, le résultat n'est pas prévisible dans le cas d'un appel avec un opérateur unaire".

C'est vrai, mais qui ferait ça ?

J'utilise dans mon code de bibliothèque :

http://emmanuel-delahaye.developpez....b/ed/inc/sys.h

Code :

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

1
2
3
 
#define FREE(p)\
   free (p), (p) = NULL

que j'utilise

Code :

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

   FREE (px);

Evidemment si quelqu'un l'utilise

Code :

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

   FREE (px++);

ben il vaut mieux qu'il change de métier...

Comme je le dit souvent "Le C n'est pas un langage de débutant".

[Thierry Chappuis]

Merci Emmanuel! Sinon, tu vois d'autres restriction à l'utilsation de macros?

Salutations

Thierry

[Médinoc]

L'autre inconvénient par rapport aux macros, c'est le manque de vérification du type. Également, le fait que Visual en mode paranoiaque gueule "condition constante" sur le do{ quelque chose }while(0) (un truc souvent utilisé dans les macros quand un bloc{} est nécessaire).
C'est pourquoi je serais plutôt du genre à n'utiliser des macros que pour ce que des fonctions inline ne peuvent pas faire: Par exemple une Item List, ou la conversion compile-time de l'opérande en chaîne, qui permet de faire ce genre de chose:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#define ITEM(x) case x: ret = #x; break;
 
char const * getConstantName(int n)
{
char const * ret = "?";
switch(n)
	{
	ITEM(UNE_CONSTANTE)
	ITEM(UNE_AUTRE_CONSTANTE)
	}
return ret;
}

Edit: Corrigé le type de retour.

[Emmanuel Delahaye]

C'est pourquoi je serais plutôt du genre à n'utiliser des macros que pour ce que des fonctions inline ne peuvent pas faire: Par exemple une Item List, ou la conversion compile-time de l'opérande en chaîne, qui permet de faire ce genre de chose:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#define ITEM(x) case x: ret = #x; break;
 
void getConstantName(int n)
{
char const * ret = "?";
switch(n)
	{
	ITEM(UNE_CONSTANTE)
	ITEM(UNE_AUTRE_CONSTANTE)
	}
return ret;
}

Je conseille de forcer l'utilisation de ';' (c'est d'ailleurs le but du 'do-while(0)')

• La lecture du code est plus cohérente
• Les indenteurs automatiques préfèrent...

et tant qu'à faire, utiliser un type retour cohérent !

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#define ITEM(x) case x: ret = #x; break
 
char const* getConstantName (int const n)
{
   char const * ret = "?";
   switch(n)
   {
	ITEM (UNE_CONSTANTE);
	ITEM (UNE_AUTRE_CONSTANTE);
   }
   return ret;
}

[benhoeil]

mon bouquin de C (Kernighan et Richie) disait qu'une macro permet éviter l'appel d'une fonction. J'en déduis qu'un appel à une fonction est coûteux (et si qqun peut m'expliquer pourquoi je veux bien savoir, je suppose qu'il y a une histoire avec la pile d'appel de fonctions ?).

sinon oui, il faut faire attention aux expressions interprétées plusieurs fois (comme le "free(p), p=NULL" où p apparaît deux fois) et aux parenthèses lors de la définition de la macro, mais si la macro est bien écrite, je pense qu'il n'y a pas de problèmes ensuite.

[Médinoc]

Pour le point-virgule, je ne suis pas sûr: Les appels à la macro ITEM() pourraient être dans une item list, qui pourrait être incluse pour faire un tableau (auquel cas, les points-virgule gèneraient...)

[Emmanuel Delahaye]

Pour le point-virgule, je ne suis pas sûr: Les appels à la macro ITEM() pourraient être dans une item list, qui pourrait être incluse pour faire un tableau (auquel cas, les points-virgule gèneraient...)

Exact, mais dans le cas d'une vraie item-list, celle-ci est incluse et on ne voit les items que dans le fichier inclus (chez moi, .itm). L'indenteur de le voit pas.

http://emmanuel-delahaye.developpez.com/clib.htm

les exemples d'item-list ne manquent pas !

C'est bien que tu ais donné un nom pour ça (item-list), car je vais pouvoir ajouter un article sur le sujet sur mon site.

[Médinoc]

C'est bien que tu ais donné un nom pour ça (item-list), car je vais pouvoir ajouter un article sur le sujet sur mon site.

Enfin, je n'ai pas "donné" de nom, il me semblait bien que le nom venait de toi... En tout cas, je l'ai déjà lu sur le forum.

[Emmanuel Delahaye]

mon bouquin de C (Kernighan et Richie) disait qu'une macro permet éviter l'appel d'une fonction. J'en déduis qu'un appel à une fonction est coûteux (et si qqun peut m'expliquer pourquoi je veux bien savoir, je suppose qu'il y a une histoire avec la pile d'appel de fonctions ?).

Un appel de fonction est un détournement de l'exécution 'normale' du code. Un peu comme si pendant un ballade, alors qu'on marche sur un chemin, on prenait un sentier de traverse pour visiter un endroit particulier. Si on ne sait pas revenir à l'endroit où on a quitter le chemin, on risque fort de se perdre. Il faut donc repérer l'endroit où l'on doit revenir (allez, soyons modernes, un relevé GPS que l'on note). Quand on a fini la visite, on rejoint notre destination grâce au GPS. Celle-ci est sure et non ambigüe.

C'est un peu ce que fait le processeur lors d'un appel de fonction. Il commence par noter l'adresse à laquelle le programme doit reprendre (juste après l'appel). Ensuite il fait l'appel et lors du return, il sait où aller.

Ces opérations d'enregistrement de l'adresse de retour, d'appel (changement d'adresse) et de retour ont un cout en mémoire et en temps.

De plus, si il y a des paramètres, il faut ajouter le temps de recopie des valeurs, le mécanisme de récupération des paramètres dans la fonction, l'espace mémoire nécessaire au stockage des valeurs etc. Rien de tout cela n'est gratuit.

Le code 'inine' (insertion directe du code sans détournement, est beaucoup plus efficace en terme de performance, et de réduction de l'utilisation de la mémoire, mais par contre, la taille du code augmente, évidemment.

Nota le code ne peut pas toujours être 'inliné'. C'est une demande faite au compilateur, qui fait ce qui est possible. A noter aussi que parfois, le compilateur 'inline' des fonctions sans qu'on lui demande (petites fonctions statiques simples, par exemple).

C'est aussi parfois le cas de certaines fonctions de bibliothèque comme memcpy(), strlen() etc.

[gege2061]

J'en déduis qu'un appel à une fonction est coûteux (et si qqun peut m'expliquer pourquoi je veux bien savoir, je suppose qu'il y a une histoire avec la pile d'appel de fonctions ?).

On va dire que ça prend du temps, il faut empiler les paramètres de la fonction sur la pile, créer les variables locales et inversemment à la sortie de la fonction.
Donc sur un système possédant peux de ressources ça peux prendre un temps non négligeable surtout q'il s'agit d'une petite fonction qui est appellée souvent.
L'utilisation des macro évite toutes ces manipulations puisque le code est recopié dans le corps de la fonction.

Par contre le préprocesseur possède des fonctionnalités assez interessante qu'il n'est pas possible de remplacer par des fonctions (cf le code de Médinoc). Et ça permet aussi de définir des constantes.

Donc les macro c'est bien, voir indispensable mais à utiliser le moins souvent possible.

[Médinoc]

En ce qui concerne l'inlining, il y a des cas pour des fonctions très petites (notamment, les accesseurs C++, mais on peut faire l'équivalent en C) prennent carrément moins de place que les instructions d'appel. Dans ces cas, le compilateur n'a même pas a choisir entre performance et taille du code.

Mais dès qu'une fonction est grosse, il vaut mieux laisser le compilateur choisir, si c'est possible.

[Jean-Marc.Bourguet]

Note supplementaire: dans le cas des processeurs modernes, les effets d'un appel de fonction sur les performances sont tres difficiles a etablir. D'une part, les appels des fonctions sont beaucoup plus populaires qu'ils ne l'etaient quand K&R1 a ete ecrit et donc les processeurs ont des primitives permettant de faire des appels de fonction efficaces. D'autre part les processeurs modernes ont de l'execution dans le desordre, de l'execution speculative, des caches, etc tout un ensemble de choses qui rendent difficile de determiner le cout isole de quelque chose parce que ce cout depend fortement du contexte; eventuellement le cout incremental peut etre nul -- parce que les ressources utilisees ne l'auraient pas ete -- ou meme negatif -- parce que utiliser des fonctions plutot que des macros ou des fonctions inline, ca reduit la taille du code et il peut tenir en memoire cache...

Pour revenir au premier point -- le cout des appels de fonctions dans les annees 70 -- il faut savoir que ni l'IBM 360, qui a une gestion des appels de sous-routines proche de ce qui se fait actuellement sur certains processeurs RISC, ni les micro-processeurs avec gestion integree de pile sont typiques de l'epoque. Un appel de fonction recursive comme le permet le C -- et le compilateur est quasiment oblige de suppose que la fonction est recursive car il ne voit generalement pas le code des fonctions appelees -- etait proportionellement beaucoup plus cher que de nos jours. La gestion des fonctions passait souvent alors par du code qui se modifiait lui-meme (plutot qu'une instruction ret, il y avait un saut absolu et la fonction modifiait l'adresse de destination; faire un appel recursif avec ce genre de chose demande quelques contorsions). L'alternative etait parfois des instructions fort complexes, comme sur le VAX par exemple, qui faisaient beaucoup plus que le strict necessaire, et on payait le prix en temps les actions supplementaires meme quand on n'en avait pas besoin.

En resume: je ne m'inquiete generalement pas du cout d'un appel de fonction.

[InOCamlWeTrust]

En resume: je ne m'inquiete generalement pas du cout d'un appel de fonction.

Moi non plus.

De plus, il ne faut pas oublier qu'en termes d'instructions machines quatre ou cinq empilements et un saut à une adresse donnée prennent encore moins de temps qu'une gestion de pile à la main.

Là où la gestion de pile à la main est intéressante, c'est lorsque l'on peut économiser le NOMBRE de paramètres à empiler et lorsque les optimisations du coeur du traitement se combinent avec celles de la gestion explicite de la pile.

[Thierry Chappuis]

Un grand merci pour toutes vos réponses fort instructives. Par ailleurs, par rapport à l'utilisation des fonctions inlines à la place d'une macro, beaucoup de programmeurs semblent encore hésiter à utiliser des outils spécifiés dans la norme C99. Cette dernière a bientôt 8 ans et je n'ai pas le recul pour évaluer où en est l'implémentation de C99 par les compilateurs actuels. Est-ce que les craintes vis-à-vis de C99 sont encore justifiées en 2006?

Thierry

[Jean-Marc.Bourguet]

Est-ce que les craintes vis-à-vis de C99 sont encore justifiées en 2006?

Oui C99 est tres peu implemente. Par exemple il me semble avoir compris que Microsoft a declare qu'ils ne l'implementeraient pas -- mais je n'utilise ni leur compilateur, ni leur OS donc je suis leurs actions de tres loin. Autre exemple, dans le cas particulier d'inline a ma connaissance l'implementation de gcc n'a toujours pas la semantique demandee par C99.

[gege2061]

Autre exemple, dans le cas particulier d'inline a ma connaissance l'implementation de gcc n'a toujours pas la semantique demandee par C99.

S'il y a bien quelque chose que je pensai fonctionnel c'était les fonctions inline puisque ça existe en C++. En effet sur le site de gcc la fonctionnalité est marquée broken avec comme explication :

C99 inline functions do not generate an external definition if declared without extern, but do if declared with extern, the opposite of GCC's handling of inline and extern inline. This will probably require existing glibc headers to be fixincluded.

[InOCamlWeTrust]

A propos de l'inlining, j'ai découvert quelque chose de fort surprenant dans le code assembleur engendré par GCC (du moins la version 3.3) ; GCC fait bien plus que recopier bêtement la fonction : il est capable d'en connaître la sémantique et adapter le code assembleur produit au contexte d'utilisation de la fonction.

J'ai remarqué celà dans le cadre d'un test et de la mise au point d'une fonction optimisée de calcul de somme de deux vecteurs de float. Je comparais une fonction écrite à la main en assembleur et une autre fonction écrite en C. Pour la partie C, le fichier contenait la fonction de calcul de somme et le programme de test qui effectuait quelques millions de fois la somme de deux vecteurs.

En compilant avec -O3 (et peut-être aussi -foptimize-sibling-calls... à moins qu'il soit déjà contenu dans -O3, je ne me souviens plus), le code produit dans la fonction même et celui produit dans le programme de test étaient très différents... mais sémantiquement égaux. J'essayerai à l'occasion de poster le code assembleur (x86), car c'est assez marrant comme phénomène.