Guru of the Week n° 32 : les macros préprocesseurs

Voici une nouvelle traduction des Guru of the Week.

Dans cet article, Herb Sutter aborde la question de l'utilité des macros préprocesseurs et s'ils sont encore utiles, dans quelles conditions.

Guru of the Week n° 32 : les macros préprocesseurs

EDIT : Retrouvez la liste de tous les Guru of the Week sur la page d'index.

Bonne lecture.

:fleche: Utilisez-vous encore les macros et pour quelles utilisations ?

J'ai un peu de mal à voir en quoi les utilisations présentées ici sont subtiles.. Classiques au mieux.

Rien de neuf je trouve, (c'est le premier Guru que je lis je m'attendais à quelque chose d'un peu plus barbu...).

Ca aurait été bien de parler aussi un peu des inconvénients à l'utilisation des macros trop complexes par exemple (debugger un code truffé de macro trop complexes et illisibles, c'est pas tip top).

Oui, j'utilise les macros très régulièrement (même pour du c++). Pour protéger les déclaration des headers, très peu pour du plateform specific (il vaut mieux utiliser une couche d'abstraction ou des factories qu'un #ifdef _PC par exemple). Comme précisé dans l'article si le delta est ridicule (une ligne de plus sur PS3, pas besoin de faire une abstraction pour un cas aussi isolé par exemple) ça peut aider.

Un exemple très intéressent que j'ai vu consiste à utiliser des macro pour décrire des structures de fichiers xml. Du coup ça permet en quelque lignes de créer toutes les structures, les tableaux, les hashmaps et tout le code de chargement. Pour un logiciel data-driven, c'est le top de pouvoir ajouter une ressource en quelques minutes. Par contre ça rejoint ce que je disais, il faut être sûr de ses macros sous peine de se taper du debug dans des lignes pleines de ## assez imbitables.

Citation:

---

Envoyé par seeme

J'ai un peu de mal à voir en quoi les utilisations présentées ici sont subtiles.. Classiques au mieux.

Rien de neuf je trouve, (c'est le premier Guru que je lis je m'attendais à quelque chose d'un peu plus barbu...).

---

Oui, c'est du très classique :)
Il ne faut pas oublié que ce GotW date de 1998 et qu'il est classé en difficulté 4 / 10 (donc relativement facile). Cela fait partie des bonnes pratiques depuis longtemps et c'est donc quelque chose de bien connu. (donc j'ai pas de doute que tu connaisses déjà ça ;) )
Mais cela reste des notions importantes pour ceux qui débutent ou ceux qui n'ont pas eu l'occasion d'étudier ce genre de chose.

Citation:

---

Envoyé par seeme

Ca aurait été bien de parler aussi un peu des inconvénients à l'utilisation des macros trop complexes par exemple (debugger un code truffé de macro trop complexes et illisibles, c'est pas tip top).

Oui, j'utilise les macros très régulièrement (même pour du c++). Pour protéger les déclaration des headers, très peu pour du plateform specific (il vaut mieux utiliser une couche d'abstraction ou des factories qu'un #ifdef _PC par exemple). Comme précisé dans l'article si le delta est ridicule (une ligne de plus sur PS3, pas besoin de faire une abstraction pour un cas aussi isolé par exemple) ça peut aider.

Un exemple très intéressent que j'ai vu consiste à utiliser des macro pour décrire des structures de fichiers xml. Du coup ça permet en quelque lignes de créer toutes les structures, les tableaux, les hashmaps et tout le code de chargement. Pour un logiciel data-driven, c'est le top de pouvoir ajouter une ressource en quelques minutes. Par contre ça rejoint ce que je disais, il faut être sûr de ses macros sous peine de se taper du debug dans des lignes pleines de ## assez imbitables.

---

Ok pour l'intérêt d'avoir une syntaxe simplifiée pour décrire les structures xml (et cela peut s'appliquer à d'autres cas). Par contre, je préfère la programmation générique aux macros : avec les macros, on n'a pas de validation des types alors qu'avec les templates, on va pouvoir vérifier toutes les conditions qui peuvent l'être à la compilation (d'ailleurs, on va publier dans les semaines à venir des articles sur Boost.Proto, permettant de définir et valider des grammaires à la compilation).

Les structures qui sont créées par les macros sont templatées ;)

Citation:

---

Envoyé par seeme

Les structures qui sont créées par les macros sont templatées ;)

---

Que veux-tu dire par là ?

Pour ma part oui j'utilise des macros, quand nécessaire, pour leur fonction première : remplacer au parsing du preprocessor.
90% des macros que j'écris le sont pour ne pas avoir à recopier un code redondant style succession de if. Evitant par la même occasion des erreurs d'innatention dûes aux c/c.
Et pour pouvoir identifier les différentes cibles et/ou du code spécifique selon la cible. Typiquement quand la cible est Debug, ajouter des traces et diverses informations pour le debug justement :mrgreen:.

Citation:

---

Envoyé par Bousk

Que veux-tu dire par là ?

Pour ma part oui j'utilise des macros, quand nécessaire, pour leur fonction première : remplacer au parsing du preprocessor.
90% des macros que j'écris le sont pour ne pas avoir à recopier un code redondant style succession de if. Evitant par la même occasion des erreurs d'innatention dûes aux c/c.
Et pour pouvoir identifier les différentes cibles et/ou du code spécifique selon la cible. Typiquement quand la cible est Debug, ajouter des traces et diverses informations pour le debug justement :mrgreen:.

---

Les macros cachent la création de structures templatées qui représentent les données chargées du xml.

Citation:

---

Envoyé par seeme

Citation:

---

Envoyé par Bousk

Que veux-tu dire par là ?

Pour ma part oui j'utilise des macros, quand nécessaire, pour leur fonction première : remplacer au parsing du preprocessor.
90% des macros que j'écris le sont pour ne pas avoir à recopier un code redondant style succession de if. Evitant par la même occasion des erreurs d'innatention dûes aux c/c.
Et pour pouvoir identifier les différentes cibles et/ou du code spécifique selon la cible. Typiquement quand la cible est Debug, ajouter des traces et diverses informations pour le debug justement :mrgreen:.

---

Les macros cachent la création de structures templatées qui représentent les données chargées du xml.

---

Qu'est ce que c'est que ce dialogue de sourd :mrgreen: ? Qu'est ce que XML vient faire là dedans 8O

Citation:

---

Envoyé par jblecanard

Qu'est ce que c'est que ce dialogue de sourd :mrgreen: ? Qu'est ce que XML vient faire là dedans 8O

---

Ca vient de mon premier post en fait :aie:

Pour bien comprendre un des exemples :
II-C-1. Code de débogage

Code:

---

1 2 3 4 5 6 7 8

void f() { #ifdef MY_DEBUG cerr << "some trace logging" << endl; #endif   // ... le reste de f() va ici... }

---

le code entre le #ifdef et #endif sera-t-il compilé si MY_DEBUG est différent de 1 ? Si oui, comment sera-t-il exécuté ensuite (à l’exécution) ?

Citation:

---

Envoyé par MicBeastKiller

Pour bien comprendre un des exemples :
II-C-1. Code de débogage

Code:

---

1 2 3 4 5 6 7 8

void f() { #ifdef MY_DEBUG cerr << "some trace logging" << endl; #endif   // ... le reste de f() va ici... }

---

le code entre le #ifdef et #endif sera-t-il compilé si MY_DEBUG est différent de 1 ? Si oui, comment sera-t-il exécuté ensuite (à l’exécution) ?

---

La compilation se passe en 2 temps : le préprocesseur passe en premier et interprète les macros pour fournir le code C++ sans macro ; puis le compilateur fait son boulot.
Donc cela revient à compiler le code suivant dans le premier cas :

Code:

---

1 2 3 4

void f() { // ... le reste de f() va ici... }

---

et le code entre les #ifdef n'apparaît pas dans le binaire
Et dans le second cas :

Code:

---

1 2 3 4 5

void f() { cerr << "some trace logging" << endl; // ... le reste de f() va ici... }

---

et le code entre les #ifdef apparaît dans le binaire

Attention : #ifdef = "if define". Ce n'est pas pareil que "#if MY_DEBUG != 1". A partir du moment où MY_DEBUG existe, c'est bon :

Code:

---

1 2 3

#define MY_DEBUG #define MY_DEBUG 1 #define MY_DEBUG ou n'importe quoi ici

---

Pour rappel, pour "supprimer" un define, il faut utiliser #undef

Code:

---

#undef MY_DEBUG

---

Citation:

---

Envoyé par gbdivers

La compilation se passe en 2 temps : le préprocesseur passe en premier et interprète les macros pour fournir le code C++ sans macro ; puis le compilateur fait son boulot.
Donc cela revient à compiler le code suivant dans le premier cas :

Code:

---

1 2 3 4

void f() { // ... le reste de f() va ici... }

---

et le code entre les #ifdef n'apparaît pas dans le binaire
Et dans le second cas :

Code:

---

1 2 3 4 5

void f() { cerr << "some trace logging" << endl; // ... le reste de f() va ici... }

---

et le code entre les #ifdef apparaît dans le binaire

Attention : #ifdef = "if define". Ce n'est pas pareil que "#if MY_DEBUG != 1". A partir du moment où MY_DEBUG existe, c'est bon :

Code:

---

1 2 3

#define MY_DEBUG #define MY_DEBUG 1 #define MY_DEBUG ou n'importe quoi ici

---

Pour rappel, pour "supprimer" un define, il faut utiliser #undef

Code:

---

#undef MY_DEBUG

---

---

Merci pour le rappel final.