Le préprocesseur

Le préprocesseur est un outil qui modifie le code source avant que le compilateur n'entre en oeuvre. Ses directives débutent toutes par un dièse (#) se trouvant dans la première colonne d'une ligne de code, et ne se terminent pas par un point virgule (;). Le langage du préprocesseur, malgré l'habitude que nous développons à son usage, n'est ni celui du langage C, ni celui du langage C++, mais bien un langage à part entière.

Sur cette page, nous poserons notre regard sur les possibilités et les limites de cet outil, en nous concentrant sur ses directives et leur effet sur les transformations apportées au code source.

Directives de définition de symboles – #define et #undef

La directive #define introduit une macro, soit un symbole qui sera remplacé par une expression (optionnelle) lors de la précompilation d'un fichier. En contrepartie, la directive #undef élimine un symbole de la liste de ceux qui sont définis.

#define sym [rempl]

#undef sym

La directive #define crée un symbole pour le préprocesseur. Ce symbole peut, de façon optionnelle, avoir une valeur. Le cas où aucun texte de remplacement n'est offert sera couvert plus bas, là où il prendra son sens.

Symboles avec texte de remplacement

Prenons l'exemple suivant, qui associe au symbole XYZ l'équivalent lexical 3.

#define XYZ 3

Ainsi, à chaque endroit où le préprocesseur rencontrera dans le texte du code source ayant défini cette directive le lexème XYZ, il le remplacera par le texte 3.

#define XYZ 3

int a = XYZ;

int a = 3;

z = f(-XYZ);

z = f(-3);

#define FRED 33
int somme(int a, int b) {
   return (a + b);
}
int main() {
   int a= -FRED* 4+ somme(FRED, -4);
}

int somme(int a, int b) {
   return (a + b);
}
int main() {
   int a= -33* 4+ somme(33, -4);
}

De manière semblable, une macro paramétrique est possible, comme par exemple :

#define min(a,b) (((a)<(b))?(a):(b))

Une telle macro provoquera un remplacement paramétrique du symbole par l'expression correspondante, en tenant compte des paramètres, mais sur une base lexicale. Ainsi :

#define min(a,b) (((a)<(b))?(a):(b))

int f();
int g();

int f();
int g();

int main() {
   int m, n;
   if (cin >> m >> n)
      cout << min(m, n) << endl;
   cout << min(f(), g()) << endl;
}

int main() {
   int m, n;
   if (cin >> m >> n)
      cout << (((m)<(n))?(m):(n)) << endl;
   cout << (((f())<(g()))?(f()):(g())) << endl;
}

Une des raisons pour lesquelles C++ préfère les templates aux macros est le remplacement lexical des expressions : ici, à gauche, pourrait penser avoir appelé f(), puis g(), et avoir trouvé la valeur minimale des deux valeurs ainsi obtenues, comme lors d'un appel de fonction, mais en pratique, nous appellerons deux fois l'une des deux fonctions (impossible d'établir laquelle au préalable).

#define A 4
#define B ((A > b)? A: b)
int main() {
   int b= 3, z= B;
}

Directives d'inclusion de fichier – #include

#include <fich.h>

#include <fich>

#include "fich.h"

La directive #include demande au préprocesseur d'inclure le texte d'un fichier à la place de la directive d'inclusion elle-même.

// cette ligne sera remplacée par le texte du fichier bits.h
#include "bits.h"
// cette ligne sera remplacée par le texte de cmath
#include <cmath>

La différence entre un fichier inclus entre <> et un autre inclus entre "" est la suivante :

• Dans le premier cas, c'est dans le répertoire des fichiers d'en-têtes standard que le préprocesseur cherchera le fichier demandé, alors que
• Dans le second cas, il cherchera d'abord dans le répertoire de travail du projet

#include "a.h"

#include "a.h"...

#include "a.h"
#include "b.h"

#include "c.h"

En effet, si on prend l'exemple d'une déclaration de type, avoir une seule déclaration qui puisse être inclue par différents fichiers source, inclure ce fichier assure que tous les fichiers sources perçoivent exactement le même type de la même manière.

Évidemment, mettre à la disposition de toutes et de tous des déclarations communes et destinées à être utilisées de manière généralisée est une chose, mais il faut bien entendu que les gens s'en servent.

enum partie_octet {
   partieHaute, partieBasse
};

#include "octets.h"

enum partie_octet {
   partieBasse, partieHaute
};

Les valeurs associées aux constantes énumérées que sont partieBasse et partieHaute dans les deux cas ne sont pas les mêmes, ce qui pourrait conduire à des problèmes de logique lors de l'exécution du programme.

Dans le schéma visible à droite, les flèches indiquent le sens de l'inclusion des fichiers.

Remarquez que bits.h est inclus par bits.cpp et par UnProjet.cpp. Ceci signifie que le texte de bits.h fera partie à la fois de bits.cpp et de UnProjet.cpp.

La même règle s'applique ici au contenu de octets.h, qui se retrouve intégralement dans octets.cpp et dans UnProjet.cpp.

Cela signifie que le type partie_octet, mentionné en exemple plus haut et déclaré dans octets.h, fait partie des fichiers octets.cpp et UnProjet.cpp mais ne fait pas partie de bits.cpp.

Directives d'inclusion conditionnelle – #if, #ifdef, #ifndef, #elif, #else et #endif

Les directives d'inclusion conditionnelle permettent de contrôler l'ajout (ou non) de régions de code dans l'unité de traduction qui sera bel et bien compilée.

#ifdef sym

#ifndef sym

#if condition

#elif [condition]

#else

#endif

#define ROGER
#define BIQUETTE 4
#ifndef ROGER
int fonctionBizarre(int z) {
   return (z * 34 - (z*z)/15);
}
#elif defined BIQUETTE && (BIQUETTE >= 3)
int fonctionBizarre(int z) {
   return ((float)z / 15 - (1.0/z));
}
#else
int fonctionBizarre(int z) {
   return (-1);
}
#endif
int main() {
   int a= fonctionBizarre(4);
}

Directives natives – #pragma

Bien que le langage C++ permette d'écrire des programmes qui soient pleinement portables (du point de vue du code source), le mot portable étant un anglicisme au sens de utilisable sur plusieurs plateformes, il est possible d'utiliser des directives natives à chaque plateforme et à chaque compilateur.

Évidemment, il y a un prix à payer pour avoir recours à des tactiques non portables (il faut une version des sources pour chaque plateforme!). Il faut donc minimiser le recours à cette tactique. Si une alternative à une directive indigène existe (par exemple, la directive #pragma once du compilateur C++ de Microsoft remplace une technique très simple et très répandue qui n'utilise que des directives portables), alors il faut éviter les directives indigènes qui ne font que nuire à la portabilité sans entraîner de réels avantages.

En retour, pour les cas très propres à un compilateur donné (par exemple, pour faire taire un avertissement très spécifique qu iest un défaut du compilateur plutôt que de votre propre code) ou à une plateforme donnée (pour utiliser une stratégie d'accès au matrériel très spécifique à un système d'exploitation), les directives indigènes (avec des commentaires en quantité suffisante pour documenter la manoeuvre) sont tout indiquées.

Nous ne couvrirons pas l'étendue des directives indigènes dans ce document – ce ne serait pas pertinent. Si vous avez envie d'en savoir plus, consultez la documentation de votre outil de travail.

#pragma <varia>

Macros « magiques »

Les préprocesseurs, pour faciliter les diagnostics dans les programmes, offrent des macros « magiques » nommées __FILE__, __LINE__ et __FUNCTION__ pour indiquer, respectivement, le nom du fichier en cours de traitement, la ligne dans ce fichier, et (si cela s'avère) le nom de la fonction en cours de traitement. Le format du texte dans ces macros n'est pas normé, et dépend du compilateur.

Par exemple :

#include <iostream>
using namespace std;
void f(int) {
   cout << __FILE__ << endl
        << __LINE__ << endl
        << __FUNCTION__ << endl;
}
void f() {
   cout << __FILE__ << endl
        << __LINE__ << endl
        << __FUNCTION__ << endl;
}
int main() {
   f();
   f(3);
   cout << __FILE__ << endl
        << __LINE__ << endl
        << __FUNCTION__ << endl;
}

z.cpp
10
f
z.cpp
5
f
z.cpp
17
main

Ceci permet entre autres une forme extrêmement limitée de réflexivité sur la structure des fichiers sources.

#include <map>
#define decl(name, type) type name
decl(kitten, int); // OK
decl(nope, std::map<int,bool>); // error: macro "decl" passed 3 arguments, but takes just 2

Macros variadiques

Le langage C permet d'écrire des macros variadiques, mais en comparaison avec les templates variadiques de C++, c'est un mécanisme très douloureux. Tout de même, si vous y tenez :

#include <iostream>
void f(int) { std::cout << "Un seul parametre\n"; }
void f(int,int) { std::cout << "Deux parametres\n"; }
void f(int,int,int) { std::cout << "Trois parametres\n"; }
#define F(...) (f(__VA_ARGS__))
int main() {
   F(2); // un seul parametre
   F(2,3,5); // trois parametres
}

Ici, __VA_ARGS__ signifie « les paramètres dans la section ... de la macro ».

Trucs et techniques

Il existe des milliers de trucs et de techniques à partir de macros. Je ne recommande pas d'en abuser : en C++, particulièrement, nous essayons de les faire disparaître le plus possible, les actions des macros échappant au compilateur et étant quelque peu hostiles à son égard.

Tout de même, les macros existent, et les gens s'en servent, alors voici quelques trucs et techniques à base de macros que vous trouverez peut-être utiles.

Le TODO

Cette technique m'a été suggérée par Peter Bindels en 2018 (source) :

Son idée est donc d'écrire une macro comme la suivante (présumant les inclusions requises faites au préalable) :

#define TODO(msg) { puts(msg); abort(); }

... pour ensuite l'utiliser à titre de rappel pour les programmeuses et les programmeurs :

void f(X *p) {
   TODO("f(X*) n'est pas encore implémentée");
}

Lectures complémentaires

Quelques liens pour enrichir le propos.

• Pour en savoir plus sur la mécanique de compilation en général, voir ../Developpement/Programmation-Systeme--Mecanique-Compilation.html
• Pour un survol des différences entre #ifdef et #if, voir ce texte de Mark Seaborn en 2015 : http://lackingrhoticity.blogspot.de/2015/01/conditionalising-c-ifdef-vs-if.html
• Pour un complément d'information sur les directives d'inclusion conditionnelles, voir ce texte de Robert C. Martin en 2014 : http://www.randomprogramming.com/2014/10/include-guards/
• Macros en C :
  • macros prédéfinies de divers compilateurs : http://predef.sourceforge.net/precomp.html
  • définir de nouvelles structures de contrôle à l'aide de macros :
    • http://almostvalid.blogspot.ca/2012/03/inline-deferred-work-in-c.html
    • http://www.rfc1149.net/blog/2012/03/17/control-structures-with-c-macros/
    • http://www.chiark.greenend.org.uk/~sgtatham/mp/
    • définir un bloc with, sorte de technique RAII, par Ricky Stewart en 2013 : http://rickystewart.wordpress.com/2013/12/17/a-preprocessor-hack-to-implement-with-blocks-in-pure-c/
    • certains visent à utiliser des macros pour transformer (en surface) C ou C++ dans un autre langage, par exemple Pascal (remplacer { par begin et } par end, par exemple). Ne faites pas ça, je vous en prie! Mais pour un exemple de cette pratique, examiner le « langage » Bournegol, qui cherche à faire passer du code C pour du code Algol : http://oldhome.schmorp.de/marc/bournegol.html
    • faire avec des macros ce qu'on ferait, en C++, avec des templates, en 2015 : http://blog.pkh.me/p/20-templating-in-c.html
• quelques trucs avec des macros :
  • texte de Mike Ash en 2010 : http://www.mikeash.com/pyblog/friday-qa-2010-12-31-c-macro-tips-and-tricks.html
  • texte de Bao Haojun en 2013 : http://baohaojun.github.io/blog/2013/05/03/z02abuse-macros-comments.html
  • formaliser une forme de mécanisme de propriétés, par Achilleas Margaritis en 2005 : http://www.codeproject.com/Articles/12358/C-object-properties-with-no-run-time-or-memory-ove (personnellement, je m'y prends autrement : ../Divers--cplusplus/Proprietes.html)
  • un FOREACH sur un conteneur plutôt que sur des itérateurs, précurseur des travaux sur les intervalles en vue de C++ 17, par Eric Niebler en 2005 : http://www.artima.com/cppsource/foreach.html
  • utiliser les macros pour améliorer les messages d'erreur, par Maciej A. Czyzewski en 2015 : http://maciejczyzewski.me/2015/02/21/better-debug-notices-in-c-using-macros.html
  • générer des séquences de code répétitives à l'aide de macros : https://en.wikipedia.org/wiki/X_Macro
• les macros variadiques :
  • https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
  • texte d'Andrzej Krzemieński en 2014 : http://akrzemi1.wordpress.com/2014/06/18/using-variadic-macros/
• les macros génériques :
  • il est possible de réaliser une forme de surcharge de fonctions à l'aide de macros génériques, comme le montre cet exemple de code par Barosl Lee : https://gist.github.com/barosl/e0af4a92b2b8cabd05a7
  • réaliser des manoeuvres de métaprogrammation avec des macros, texte de Martin Sústrik en 2015 : http://250bpm.com/blog:56
• des macros de haut niveau, un texte de Robert Nystrom en 2012 : http://journal.stuffwithstuff.com/2012/01/24/higher-order-macros-in-c/
• Quelques bogues qui ne peuvent arriver que dans de telles circonstances : http://www.elpauer.org/?p=971
• Abuser du préprocesseur : http://altdevblogaday.com/2011/07/12/abusing-the-c-preprocessor/
• Réaliser un Currying (en apparence) avec des macros, texte de 2013 : http://almostvalid.blogspot.ca/2013/05/curried-functions-in-c.html
• Comment fonctionne le préprocesseur? Texte de Nicolás Brailovsky en 2013 : http://monoinfinito.wordpress.com/series/c-preprocessor-internals/
• Texte sur la « magie » du préprocesseur, par Jonathan Heathcote en 2014 : http://jhnet.co.uk/articles/cpp_magic
• Utiliser le préprocesseur pour... générer des sites Web statiques, par Sergey Ignatchenko en 2012 : http://ithare.com/compiling-a-static-web-site-using-the-c-preprocessor
• Le préprocesseur est-il Turing-Complete? Texte de 2012 par Daniel Holden : http://theorangeduck.com/page/c-preprocessor-turing-complete
• Critiques :
  • l'enfer de la compilation conditionnelle, décrit par Florian Deißenböck en 2015 : https://www.cqse.eu/en/blog/living-in-the-ifdef-hell/
• Texte de Randy Gaul en 2016 à propos de #ifdef et de #if : http://www.randygaul.net/2016/07/07/ifdef-vs-if-and-if/
• Exemple un peu malpropre de manoeuvre avec des macros pour inclure une liste de fichiers, par Jordan Rose en 2016 : http://belkadan.com/blog/2016/08/Macromancy/

#pragma pp-tokensopt new-line 

• La technique des XMacros, pour répéter une opération sur une liste de variables  : https://en.wikipedia.org/wiki/X_Macro
• En 2017, Raymond Chen explique un comportement susceptible de surprendre avec une macro « magique » comme __FILE__ : https://blogs.msdn.microsoft.com/oldnewthing/20170417-00/?p=95975
• Texte d'Arne Mertz en 2018 sur la saine gestion et le sain usage des directives #include : https://arne-mertz.de/2018/03/include-dont-get-fancy/
• Petit guide pour écrire des macros variadiques pour imprimer des valeurs à la console, par Sean Murthy en 2020 : https://sigcpp.github.io/2020/07/10/variadic-print-macros