Utilisation des macros: bien ou mal?

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:

---

1 2 3 4

#if defined(UNE_MACRO) /*...un bout de code ...*/ #endif

---

On peut alors définir UNE_MACRO à la compilation:

Code:

---

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:

---

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

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

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:

---

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

Citation:

---

Envoyé par mujigka

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:

---

1 2 3

#define FREE(p)\   free (p), (p) = NULL

---

que j'utilise

Code:

---

FREE (px);

---

Evidemment si quelqu'un l'utilise

Code:

---

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".

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

Salutations

Thierry

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:

---

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. :oops:

Citation:

---

Envoyé par Médinoc

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:

---

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:

---

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; }

---

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.

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...)

Citation:

---

Envoyé par 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...)

---

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.

Citation:

---

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.

Citation:

---

Envoyé par 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 ?).

---

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.

Citation:

---

Envoyé par benhoeil

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.

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.

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.

Citation:

---

Envoyé par Jean-Marc.Bourguet

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.

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

Citation:

---

Envoyé par mujigka

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.

Citation:

---

Envoyé par Jean-Marc.Bourguet

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

---

8O 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 :

Citation:

---

Envoyé par [url=http://gcc.gnu.org/c99status.html]Status of C99 features in GCC[/url]

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.

---

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.

Citation:

---

Envoyé par gege2061

8O S'il y a bien quelque chose que je pensai fonctionnel c'était les fonctions inline puisque ça existe en C++.

---

gcc a le comportement du C++ (extern inline est une extension), pas celui du C99. Ne me demande pas pourquoi en C99 on n'a pas pris le comportement du C++...

Citation:

---

Envoyé par 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.

---

Les compilateurs essaient l'inliner assez tôt pour permettre ce genre de choses. La propagation des constantes dans du code inline peut avoir des effets époustouflants.

Excuse-moi, mais je n'ai pas bien saisi ce que tu veux dire par "inliner tôt" et "propagation des constantes".

Citation:

---

Envoyé par InOCamlWeTrust

Excuse-moi, mais je n'ai pas bien saisi ce que tu veux dire par "inliner tôt" et "propagation des constantes".

---

Les compilateurs implémentent plusieurs optimisations (Munchnick dans Advanced Compiler Design and Implementation en donne une cinquantaine). De mémoire, on fait l'inlining assez tôt parce que c'est une optimisation qui a tendance à en permettre d'autres.

Propager les constantes, c'est déterminer quelles variables contiennent une valeur constante (même si l'expression n'est pas constante pour le langage) et remplacer la variable par la valeur. Dans le cas de paramètres de fonction, on peut parfois supprimer pas mal de code en faisant ça.

Citation:

---

Envoyé par InOCamlWeTrust

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.

---

mais justement, si j'ai bien compris, on ne gère pas du tout de pile en passant par une macro puisqu'on évite l'appel de fonction et que l'exécution suit son "cours normal". Donc à priori ça serait toujours ça de gagné.

Mais si ce que dis Jean-Marc est vrai (moi j'y crois !), ça ne serait pas grand chose de gagné.

Bon je passais simplement pour un petit merci pour toutes ces réponses !

Donc, pour faire une petite synthèse, actuellement encore, seul C89 assure une portabilité maximale. Microsoft a décidé de ne pas imlémanter la nouvelle norme, tandis que l'implémantation de GCC est incomplète (quelques retours d'expériences sur d'autres compilateurs tels que lcc ou d'autres?):

http://gcc.gnu.org/c99status.html pour le status de C99 dans GCC

En particulier, l'implémantation des fonctions inline par GCC ne respecte pas la norme C99 et possède le status "broken". Ainsi, l'utiliation du pré-processeur reste nécessaire pour optimiser des fonctions de taille raisonnable en économisant le surcoût des appels de fonction.

Médinoc ajoute que le passage par macro ne permet pas de vérification de type, et J-M Bourget ne pense pas que le surcoût engendré par des appels de fonction sont un handicap sur les processeurs actuels, et ne s'en inquiète pas. Supposons donc qu'on se limite à l'utilisation de C89. Compte tenu que les appels de fonctions semblent présenter un surcoût raisonnable en terme de performance, y a-t'il parmi vous des adeptes du "tout fonction" qui préfèrent systématiquement un appel de fonction (même mon inlinée) à l'utilisation d'une macro?

Merci encore pour vos réponses fort intéressantes et meilleures salutations

Thierry

Citation:

---

Envoyé par mujigka

En particulier, l'implémantation des fonctions inline par GCC ne respecte pas la norme C99 et possède le status "broken".

---

A noter qu'il est possible d'utiliser les fonctions inline de gcc de maniere compatible avec C99. C'est seulement quand on commence a jouer avec des particularites de la visibilite entre unites de compilation (la meme fonction inline dans un et pas dans l'autre) ou peut-etre des choses comme des variables statiques dans une fonction inline que ca joue un role.

Citation:

---

Compte tenu que les appels de fonctions semblent présenter un surcoût raisonnable en terme de performance, y a-t'il parmi vous des adeptes du "tout fonction" qui préfèrent systématiquement un appel de fonction (même mon inlinée) à l'utilisation d'une macro?

---

Oui. Pour une autre raison: utiliser des fonctions non inline reduit le couplage (modifier l'implementation d'une fonction ne force pas a recompiler toutes les unites qui l'utilise). Passer a des fonctions inlines ou des macros c'est de l'optimisation. Rappel:

Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
- M.A. Jackson

"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity."
- W.A. Wulf

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
- Donald Knuth

Citation:

---

Envoyé par Jean-Marc.Bourget

A noter qu'il est possible d'utiliser les fonctions inline de gcc de maniere compatible avec C99. C'est seulement quand on commence a jouer avec des particularites de la visibilite entre unites de compilation (la meme fonction inline dans un et pas dans l'autre) ou peut-etre des choses comme des variables statiques dans une fonction inline que ca joue un role.

---

Aurais-tu un exemple de code où la compatibilité est respectée et un autre où des problèmes évidents apparaissent avec GCC. Il faudra que j'étudie ça, car ça m'intéresse! (Au passage, quelqu'un connaît-il un compilateur qui implémente C99 dans sa totalité ...et quelqu'un y a-t'il une idée des raison lesquelles certains compilateurs ont décidé de ne pas implémanter cette norme).

L'usage intempestif de macros, c'est donc de l'optimisation prématurée et déconseillée aux débutants. Il est donc raisonnable de proner l'utilisation systèmatique de fonctions (non inlinées), même pour l'implémentation de fonctions de petite taille auxquelle on fait souvent appel, en tout les cas dans la phase préliminaire du codage.

Meilleures salutations

Thierry

Citation:

---

Envoyé par benhoeil

mais justement, si j'ai bien compris, on ne gère pas du tout de pile en passant par une macro puisqu'on évite l'appel de fonction et que l'exécution suit son "cours normal". Donc à priori ça serait toujours ça de gagné.

Mais si ce que dis Jean-Marc est vrai (moi j'y crois !), ça ne serait pas grand chose de gagné.

Bon je passais simplement pour un petit merci pour toutes ces réponses !

---

Je parlais de la vraie récursivité VS récursivité "gérée à la main" avec pile logicielle.