Prenons le cas académique d'une instruction de sortie standard comme celle ci‑dessous, dont la chaîne de format contient des caractères accentués.

#include <stdio.h>

int main(void)
{
  printf("Connecté au réseau.\n");
  return 0;
}

Typiquement, si le fichier source – nommé par exemple, testCharset.c :

• est codé sur un PC Windows dans le format CP1252 (cf. chap. C3‑VIII )
• puis compilé sur un PC Linux sans option, puis exécuté sur cette même machine,

alors on obtient un remplacement de chaque occurrence de la lettre « é » par un caractère de substitution (cf. chap. C3‑VIII ) :

gcc testCharset.c -o testCharset && ./testCharset 
Connect� au r�seau.

En revanche, si ce même fichier source est compilé avec l'option de transcodage appropriée, on obtient une sortie correcte des caractères accentués :

gcc -finput-charset=Windows-1252 testCharset.c -o testCharset && ./testCharset 
Connecté au réseau.

Remarque. Rappelons que le transcodage du jeu de caractères du fichier source peut également être opéré avec l'éditeur de code, avant tout appel de la chaîne de compilation.

Par exemple, avec Sublime Text, il suffit de cliquer sur l'indication de format dans la barre de notifications et de sélectionner le format UTF‑8 via le menu déroulant (cf. chap. C3‑VIII . Le fichier source étant ainsi préalablement transcodé, le préprocesseur se trouve déchargé de cette tâche.

Si un programme est compilé sous Linux mais destiné à être exécuté sous Windows – on parle alors de compilation croisée (cf. chap. C4‑IV ) – on peut saisir l'option :
-fexec-charset=windows-1252
en veillant à ce que cette page de code soit bien activée dans la fenêtre de terminal d'exécution (cf. chap. C3‑VIII ).

Dans le premier exemple supra , on peut voir que les tabulations d'indentation – d'une valeur de 2 espaces – présentes dans le fichier source au début des lignes nº 6 & 8 ont été remplacées dans le ficher prétraité par de simples espaces au début des lignes nº 12 & 14.

int main(void)
{
  a++;
  // no output
  return 0;
}

int main(void)
{
 a++;

 return 0;
}

Dans le premier exemple supra , six marques de ligne apparaissent au début du fichier prétraité obtenu par appel de la commande cpp (on les retrouve en principe dans tous les programmes) :

# 0 "simpleProg.c"
# 0 "<built-in>"
# 0 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "<command-line>" 2
# 1 "simpleProg.c"

On peut ainsi retracer certains prétraitements « cachés » de la chaîne de compilation :

• # 0 "simpleProg.c" signale que le préprocesseur commence son travail à la ligne nº 0 du fichier simpleProg.c, qui est ici le seul fichier source. Cette indication sert surtout à préciser le nom du fichier source, car son prétraitement effectif est immédiatement différé par ce qui suit.
• # 0 "<built-in>" signale que le préprocesseur commence (à partir de la ligne nº 0) le prétraitement du fichier virtuel built-in où sont codées des directives qui prédéfinissent des pseudo‑constantes des langages C/C++ permettant d'obtenir la valeur de nombreuses variables d'environnement (cf. infra ).
• # 0 "<commande-line>" signale que le préprocesseur commence (à partir de la ligne nº 0) le prétraitement du fichier virtuel command-line où sont codées des directives qui prédéfinissent des pseudo‑constantes qui sont spécifiques à la ligne de commande (en fonction des options de compilation choisies ou par défaut) ainsi qu'au terminal d'exécution.
• # 1 "/usr/include/stdc-predef.h" 1 3 4 signale que le préprocesseur commence (à partir de la ligne nº 1) le prétraitement d'un nouveau fichier – d'où le drapeau 1 – dont le chemin d'accès est /usr/include/stdc-predef.h. On verra qu'il s'agit en fait d'une directive d'inclusion. On a également le drapeau 3 puisqu'il s'agit d'un fichier d'en‑tête et le drapeau 4 puisque ce fichier contient du code en langage C.
• # 0 "<commande-line>" signale que le préprocesseur reprend à la ligne nº 0 le prétraitement du fichier virtuel command-line. Le drapeau 2 indique qu'il s'agit d'un retour (après la prise en compte de la directive d'inclusion du fichier stdc-predef.h qui vient d'avoir lieu).
• # 1 "simpleProg.c" signale que le préprocesseur commence (cette fois pour de bon) à la ligne nº 1 le prétraitement du fichier source simpleProg.c.
Comme il n'y a pas de directives d'inclusion codées dans ce fichier, il n'y a pas d'autres marques de ligne qui suivent dans le fichier prétraité généré par la commande cpp.

À la ligne nº 11 du fichier source de l'exemple précédent  :

  printf("(taux de TVA appliqué %.1f %%)\n", TVA * 100);

le préprocesseur n'a pas effectué d'expansion dans la chaîne de format de la fonction printf puisqu'il s'agit d'une chaîne de caractères et que les trois lettres successives « TVA » qui y figurent ne constituent pas un identificateur.

Il en serait de même si l'on avait codé la macro‑définition d'une deuxième pseudo‑constante à la suite de la première, comme par exemple  :

#define FACTEUR_TVA (1 + TVA)

Lors de l'expansion de la première macro‑définition, le préprocesseur aurait opéré à la ligne nº 4 la substitution de l'identificateur TVA par 0.055 dans l'expression (1 + TVA) (ou l'identificateur TVA est utilisé) mais pas dans l'identificateur FACTEUR_TVA car il ne peut pas être décomposé (c'est un atome).

1. On a vu au chap. C3‑III  que les langages C/C++ ne disposaient pas de symboles spécifiques pour coder les opérateurs booléens xor (ou exclusif ) et xnor.
Néanmoins, il est très facile de pallier cette lacune en codant les deux macro‑définitions suivantes :

#define xor  !=
#define xnor ==

Elles permettent ensuite d'employer les identificateurs xor et xnor comme des opérateurs, respectivement à la place des opérateurs de comparaison != et == qui, l'un comme l'autre, ne sont pas lisibles comme opérateurs booléens.
Remarques.
• De telles directives ne définissent ni des pseudo‑constantes (car leur chaîne de substitution n'est pas une constante littérale), ni des pseudo‑fonctions (car elles n'ont pas d'argument).
• Il n'est pas possible de procéder de même pour définir les opérateurs booléens nand et nor. En effet, ces deux opérateurs sont seulement codables l'un comme l'autre par composition de deux opérateurs . On peut donc les macro‑définir comme des pseudo‑fonctions, mais pas comme des opérateurs.
2. À éviter ! Un francophone « allergique » à l'anglais pourrait être tenté de coder le programme ci‑dessous, qui commence par quatre directives pour définir des synonymes français aux mots‑clefs et autres éléments de langages prédéfinis :

#include <stdio.h>

#define entier              int 
#define retourne            return
#define fonctionPrincipale  main
#define vide                void
#define affiche             printf

entier fonctionPrincipale(vide)
{
  affiche("Bonjour, Monde !");
  retourne 0;
}

Grâce au préprocesseur, ce programme serait parfaitement compilable et exécutable, en C comme en C++. Et en effet, si l'on observait le contenu du fichier prétraité engendré par la commande cpp, on y retrouverait tous les éléments de langage originaux :

int main(void)
{
  printf("Bonjour, Monde !");
  return 0;
}

Toutefois, même pour un codeur débutant, une telle démarche est vivement déconseillée. En effet, au delà d'une hypothétique commodité individuelle, ces macro‑définitions nuisent gravement à la lisibilité du code. En définissant de tels synonymes, on s'exclut de la communauté des codeurs expérimentés et dans la perspective d'un futur projet en équipe, il faut en effet penser à tous les lecteurs potentiels du code qui n'auront pas en tête ces directives de « traduction » personnelles et ne voudront pas prendre du temps pour se familiariser avec.

Dans le programme académique ci‑dessous, la directive codée en ligne nº 3 redéfinit le mot‑clef const par une chaîne de substitution vide :

#include <stdio.h>

#define const   // empty substitution string => keyword deleted below

int main(void)
{
  const int a = 5;
  a = 0;
  printf("%d\n", a);
  return 0;
}

Autrement dit, à partir de la ligne nº 4, le préprocesseur supprime purement et simplement toutes les occurrences du mot‑clef const. De ce fait, la donnée a déclarée en ligne nº 6 devient une variable et peut faire l'objet d'une nouvelle affectation comme celle codée en ligne nº 7.

Bien évidemment, cet exemple n'est surtout pas à suivre systématiquement (il n'y a pas d'intérêt à déclarer une constante pour ensuite vouloir changer sa valeur par une astuce). Mais pour adapter un code source volumineux à une chaîne de compilation ancienne qui ne comprend pas le mot‑clef const (car il n'a pas toujours existé en langage C), il est bien plus commode de recourir à une directive astucieuse plutôt que de procéder par des copier‑coller fastidieux dans tous les fichiers source du programme.

Dans le code académique (incomplet) ci‑dessous :

enum {AM, PM} midDay;

#define  AM AM

• on déclare une variable de type énuméré anonyme dont chaque élément (AM, PM) est, rappelons‑le, implicitement une constante déclarée de type int (cf. chap. C3‑IV ) ;
• et on code (avant ou après, peu importe) une macro‑définition homonyme – donc récursive – de AM ; il s'agit donc d'une pseudo‑constante (sa valeur vaut 0).

L'intérêt d'une telle directive est qu'elle permet ensuite coder une ligne de contrôle de compilation conditionnelle comme par exemple #ifdef AM.

Dans le programme académique ci‑dessous de calculs financiers, la macro‑définition de la pseudo‑constante TVA à la ligne nº 3 est surchargée par celle de la ligne nº 9 avec une valeur différente.

#include  <stdio.h>

#define     TVA   0.055 // %

int main(void)
{
  printf("(taux de TVA appliqué %.1f %%)\n", TVA * 100);

#define     TVA   0.2  // %
  
  printf("(taux de TVA appliqué %.1f %%)\n", TVA * 100);
  return 0;
}

À l'invocation de la commande cpp ou gcc, même sans option particulière, on obtient donc un avertissement, comme ci‑dessous :

gcc testDefineTVA2.c -o testDefineTVA2

testDefineTVA2.c:8: warning: "TVA" redefined
    9 | #define     TVA   0.2   // %
      | 
testDefineTVA2.c:3: note: this is the location of the previous definition
    3 | #define     TVA   0.055 // %
      |  

Néanmoins, la compilation n'échoue pas et on obtient une exécution satisfaisante avec la sortie ci‑dessous :

./testDefineTVA2
(taux de TVA appliqué 5.0 %)
(taux de TVA appliqué 20.0 %)

Dans le programme académique ci‑dessous, après la déclaration à la ligne nº 3 de la constante globale TVA, on surcharge à la ligne nº 9 son identificateur avec la macro‑définition d'une pseudo‑constante qui change sa valeur.

#include  <stdio.h>

const float TVA = 0.055; // %

int main(void)
{
  printf("(taux de TVA appliqué %.1f %%)\n", TVA * 100);

#define     TVA   0.2    // %

  printf("(taux de TVA appliqué %.1f %%)\n", TVA * 100);
  return 0;
}

La chaîne de compilation opère sans avertissement et l'exécution du programme se déroule comme pour l'exemple précédent, ainsi qu'on peut s'y attendre. Dans le fichier prétraité généré par la commande cpp, on obtient :

const float TVA = 0.055;

int main(void)
{
  printf("(taux de TVA appliqué %.1f %%)\n", TVA * 100);



  printf("(taux de TVA appliqué %.1f %%)\n", 0.2 * 100);
  return 0;
}

On voit donc que la déclaration de la constante globale TVA est intacte, puisqu'elle est antérieure à la macro‑définition. Mais après l'emplacement où figurait la macro (ligne nº 733), cette déclaration devient inopérante : l'identificateur surchargé a été remplacé par la constante littérale 0.2.

Remarque. En revanche, si on avait codé la macro‑définition de TVA avant la déclaration de la constante globale du même nom, cette déclaration serait devenue non compilable après prétraitement par le préprocesseur :
const float 0.2 = 0.055;

Dans le programme académique ci‑dessous, avant la déclaration à la ligne nº 5 de la constante globale TVA, on surcharge à la ligne nº 3 son identificateur avec une macro‑définition qui le transforme en VAT (sigle anglais signifiant value added tax).

#include  <stdio.h>

#define     TVA   VAT

const float TVA = 0.055; // %

int main(void)
{
  printf("(taux de TVA appliqué %.1f %%)\n", TVA * 100);
  return 0;
}

Là encore, la chaîne de compilation opère sans avertissement et on obtient une exécution normale du programme. Dans le fichier prétraité généré par la commande cpp, on obtient :

const float VAT = 0.055; 

int main(void)
{
  printf("(taux de TVA appliqué %.1f %%)\n", VAT * 100);
  return 0;
}

Remarque. Dans cet exemple, la surcharge n'a pas vraiment d'utilité dans la mesure où, a priori, on a aucune raison de générer le fichier prétraité, sauf pour vérifier le travail accompli par le préprocesseur.

Dans le programme académique ci‑dessous, la chaîne de substitution de la macro‑définition codée en ligne nº 3 invoque l'identificateur TVA qui n'est pas encore défini (il l'est à la ligne suivante).

#include  <stdio.h>

#define     TVA_100  (TVA * 100)
#define     TVA       0.055 

int main(void)
{
  printf("(taux de TVA appliqué %.1f %%)\n", TVA_100);
  return 0;
}

Pourtant la compilation s'effectue sans avertissement et on obtient une exécution normale. Dans le fichier prétraité généré par la commande cpp, on obtient :

int main(void)
{
  printf("(taux de TVA appliqué %.1f %%)\n", (0.055 * 100));
  return 0;
}

Comme le préprocesseur a‑t‑il opéré ?

• Il a prétraité la première directive #define en scannant le fichier source. Il a trouvé la ligne nº 7 une occurrence de l'identificateur TVA_100 qu'il a remplacée par (TVA * 100).
• Puis il a prétraité la deuxième directive #define en scannant le code qu'il a déjà prétraité. Il a donc trouvé une occurrence de l'identificateur TVA qu'il a remplacée par 0.055.

Et il en aurait fait de même pour toute autre occurrence de la pseudoTVA_100 codée après sa macro‑définition.

On verra au chapitre C5‑III  qu'en langage C ou C++, l'initialisation d'une variable de type tableau peut être effectuée par une liste d'expressions.

Si, dans un programme, une liste particulière était d'usage multiple, il serait souhaitable de la déclarer comme une constante, dans un objectif légitime de factorisation du code. Malheureusement, cela n'est syntaxiquement pas possible.

En revanche, rien n'interdit d'utiliser, comme dans l'exemple académique ci‑dessous, une macro‑définition qui n'est pas une pseudo‑constante puisque sa chaîne d'expansion est une liste (un type d'objet qui n'existe pas en langage C) :

#define  INITIAL_SPEED_VALUES  1.05, 5.001, -3.2

double speedVector[3] = { INITIAL_SPEED_VALUES };

Supposons que l'on veuille mémoriser dans un tableau les 100 premiers nombres premiers. En langage C, il est pertinent de vouloir coder la valeur 100 dans une pseudo‑constante, nommée par exemple NUMBER_OF_PRIMES, car on en aura besoin à la fois pour déclarer le tableau, et pour parcourir ses éléments avec une boucle de répétition for. Le programme pourra donc débuter par le code ci‑dessous :

#include <stdio.h>
#include <stdbool.h>

#define NUMBER_OF_PRIMES 100

bool isNotPrime(int n);

int main(void)
{
  int primes[NUMBER_OF_PRIMES] = {2, 0};
  int testedNumber = 3;
  printf("The %d first prime numbers are: \n", NUMBER_OF_PRIMES);
  printf("%4d", 2);
  for (int i = 1; i < NUMBER_OF_PRIMES; i++) { 
    // ...

On peut deviner l'existence d'un tel mécanisme d'optimisation en compilant dans l'IDE Arduino le programme blink ci‑dessous (cf. chap. C2‑IX ) :

#define BLINK_HALF_PERIOD 500              // comment to test the difference
// const uint16_t BLINK_HALF_PERIOD = 500; // uncomment to test the difference

void setup()
{
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop()
{
  digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
  delay(BLINK_HALF_PERIOD);
}

En effet, que l'on utilise la ligne nº 1 (macro‑définition d'une pseudo‑constante) ou la ligne nº 2 (déclaration d'une constante) pour mémoriser la valeur de la demi‑période de clignotement, aucune différence n'apparaît dans le résultat de la compilation affiché par Arduino IDE :

Le croquis utilise 960 octets (2%) de l'espace de stockage de programmes. Le maximum est de 32256 octets.
Les variables globales utilisent 9 octets (0%) de mémoire dynamique, ce qui laisse 2039 octets pour les variables locales. Le maximum est de 2048 octets.

sachant que les 9 octets utilisés correspondent à des données cachées, présentes même avec un programme vide.

Dans le code maladroit ci‑dessous :

#define NOMINAL_VOLTAGE  13
#define STARTING_VOLTAGE (NOMINAL_VOLTAGE / 2)

le codeur a oublié de coder les points décimaux « de précaution », notamment à la valeur de la pseudo‑constante NOMINAL_VOLTAGE (il aurait dû coder 13.0). Il en résulte que la pseudo‑constante STARTING_VOLTAGE prend, après expansion des macro‑définitions, la valeur entière 6 et non pas la valeur décimale 6.5 qu'il est logique d'attendre, étant donné ce que cette pseudo‑constante est censée représenter – une tension, donc fondamentalement un nombre décimal.

Une telle erreur serait évitée en recourant à une « vraie » constante déclarée comme par exemple ci‑dessous :

const double NOMINAL_VOLTAGE = 13;
const double STARTING_VOLTAGE = NOMINAL_VOLTAGE / 2;

En effet, même en l'absence des points décimaux dans les constantes littérales 13 et 2, la STARTING_VOLTAGE prend la valeur 6.5 car dans l'expression NOMINAL_VOLTAGE / 2, la constante NOMINAL_VOLTAGE impose son type décimal et conduit le compilateur à une évaluation correcte.

1. Avec l'opérateur « stringizing », la pseudo‑fonction str évoquée ci‑dessus se code tout simplement :
   #define str(s) #s // OK!

2. Reprenons le programme d'essai de la pseudo‑fonction swapValue proposé supra . Grâce à l'opérateur « stringizing », plutôt que de répéter l'instruction d'affichage du résultat dans le corps de la fonction main, on peut la coder dans la chaîne de substitution de la pseudo‑fonction, comme ci‑dessous à la ligne nº 6 :

#include <stdio.h>

#define swapValues(a, b) do { \
  double c = a; \
  a = b, b = c; \
  printf("After swap: %s = %g   %s = %g\n", #a, (double) a, #b, (double) b); \
} while (0) 

int main(void)
{ 
  float x = 1.0, y = 2.0;
  swapValues(x, y);
  printf("\n");

  int u = 1, v = 2;
  swapValues(u, v);
  return 0;
}

Dans la chaîne de format "After swap…" de l'appel de la fonction printf, les identificateurs des deux variables à permuter sont introduits par des spécifications de conversion %s de chaînes de caractères avec pour arguments respectifs #a et #b codés après la chaîne de format.
Remarque : dans cette même ligne, on recourt à la conversion explicite (cf. chap. C3‑VI ) dans le type double des arguments a et b pour que leurs valeurs soient systématiquement rendues compatibles avec les spécifications de conversion %g.

Supposons que l'on veuille facilement convertir toutes les constantes littérales décimales d'un programme dans l'un des trois types standards d'encodage float (suffixe f ou F), double (type par défaut, pas de suffixe) ou long double l ou L) – cf. chap. C3‑V .

Il serait difficile d'effectuer une telle manipulation avec un éditeur de code par une procédure du type rechercher/remplacer. En effet, d'une part les constantes littérales sont potentiellement toutes différentes et d'autre part, une fois codés, les suffixes ne sont pas des symboles isolés. Ils peuvent être confondus avec d'autres usage de leur lettre.

Une solution consiste par exemple à coder, comme ci‑dessous à la ligne nº 3 la pseudo‑fonction fps (pour floating point suffix) qui concatène le suffixe voulu à droite de son argument :

#include <stdio.h>

#define fps(x) x ## F

int main(void)
{
  printf("Pi = %.8f\n", fps(3.141592653));
  return 0;
}

Il faut alors invoquer cette pseudo‑fonction à chaque emploi d'une constante littérale décimale. Ensuite, pour changer le type d'encodage de toutes les constantes dans le programme, il n'y a plus qu'à modifier la chaîne de substitution dans la définition de fps (pour le type double qui n'a pas de suffixe, on code simplement x, sans opérateur de concaténation).

1. Le programme académique ci‑dessous est codé pour afficher une approximation du nombre π sous la forme d'une chaîne de caractères :

#include <stdio.h>

#define PI 3.1415926535
#define str(s) #s

int main(void)
{ 
  printf("Pi = %s\n", str(PI)); // do not work! PI is not expanded :(
  return 0;
}

Toutefois, il n'est pas opérationnel : en effet, dans le fichier prétraité généré par la commande cpp, la ligne nº 7 devient :

  printf("Pi = %s\n", "PI"); 

Par conséquent, même si ce code est compilable, son exécution n'est pas satisfaisante puisqu'on obtient en sortie standard Pi = PI.
2. Le programme académique ci‑dessous codé pour afficher une approximation du nombre π encodé dans le type float :

#include <stdio.h>

#define PI 3.141592653
#define fps(x) x ## F

int main(void)
{
  printf("%.8f\n", fps(PI));
  return 0;
}

n'est pas compilable. En effet, dans le fichier prétraité généré par la commande cpp, la ligne nº 8 devient :

  printf("Pi = %.8f\n", PIF);

alors qu'on aurait attendu que l'expansion de l'expression fps(PI) aboutisse à 3.141592653F.

1. Reprenons le programme académique donné à l'exemple 1 supra. Pour résoudre le problème d'expansion, il suffit de coder par exemple :

#include <stdio.h>

#define PI 3.141592653
#define str(s) #s
#define xstr(s) str(s)

int main(void)
{ 
  printf("Pi = %s\n", xstr(PI));
  return 0;
}

et l'exécution devient satisfaisante. En effet, la pseudo‑fonction xstr n'emploie pas l'opérateur #, donc le préprocesseur procède à son expansion en commençant par celle de son argument effectif, comme indiqué ci‑dessous :
xstr(PI)   →   xstr(3.14…)   →   str(3.14…)   →   #3.14…   →   "3.14…"
2. Reprenons le programme académique donné à l'exemple 2 supra. Pour résoudre le problème d'expansion, il suffit de coder par exemple :

#include <stdio.h>

#define PI 3.1415926535
#define fps(x) x ## F
#define xfps(x) fps(x)

int main(void)
{
  printf("Pi = %.8f\n", xfps(PI));
  return 0;
}

et l'exécution devient satisfaisante. L'expansion se déroule de façon similaire à celle de l'exemple précédent :
xfps(PI)   →   xfps(3.14…)   →   fps(3.14…)   →   3.14… ## F   →   3.14…F

La pseudo‑fonction sq pourrait ainsi être codée avec un deuxième argument formel nommé Type pour imposer une conversion explicite de l'expression à substituer, comme dans la macro‑définition ci‑dessous :

#define sq(x, Type) ((Type)((x)*(x)))

Dans une expression d'invocation de cette pseudo‑fonction, le deuxième argument effectif coderait alors un type particulier, par exemple :
sq(5.0F, float)
pour que l'expansion génère une conversion explicite dans le type float.

Pour illustrer les risques de dysfonctionnement, considérons le programme académique ci‑dessous qui tente maladroitement d'afficher le carré d'un nombre incrémenté puis la valeur de ce dernier. À la ligne nº 8, la pseudo‑fonction sq non‑sûre est composée avec l'opérateur à effet de bord ++ :

#include <stdio.h>

#define sq(x) ((x)*(x))    // warning: unsafe macro!

int main(void)
{
  int a = 2;
  printf("%d\n", sq(a++)); // 6!!
  printf("%d\n", a);       // 4!
  return 0;
}  

À l'exécution, on obtient en sortie standard successivement l'affichage de :

• 6 qui est censée être la valeur de a élevée au carré ;
• 4 qui est censée être la valeur de a après son incrémentation unitaire.

Et en effet, lors de expansion de la pseudo‑fonction sq par le préprocesseur, l'expression d'invocation sq(a++) devient ((a++)*(a++)). Il en résulte que, conformément aux règles de priorité et de sens d'associativité des opérateurs (cf. chap. C2‑IV ) :

• l'évaluation du premier terme (a++) conduit au remplacement de la variable a par sa valeur initiale 2 puis à son incrémentation ;
• l'évaluation du deuxième terme (a++) conduit au remplacement de la variable a par sa nouvelle valeur 3 puis encore à son incrémentation ;
• le produit (a++)*(a++) devient donc 2*3 et la variable a vaut alors 4 !

La bonne pratique consiste évidemment à ne pas coder une telle composition mais procéder en deux étapes, comme par exemple ci‑dessous :

int main(void)
{
  int a = 2;
  a++;
  printf("%d\n", sq(a));  // 9
  printf("%d\n", a);      // 3
  return 0;
}  

Remarque. Dans cet exemple :

• le résultat peut sembler « moins grave » si l'on code l'expression d'invocation sq(++a). La variable a étant incrémentée avant toute évaluation, on obtient successivement les valeurs 16 et 4 ; néanmoins, le problème de la double incrémentation perdure…
• le résultat devient satisfaisant si, en plus de l'amélioration ci‑dessus, à la ligne nº 3, on remplace le code de sq par celui d'une vraie fonction comme ci‑dessous :

int sq(int x) {return x*x;}

car on obtient alors les valeurs attendues 9 et 3.

Les fichiers du framework Arduino utilisent occasionnellement des directives #warning et #error. Les exemples ci‑dessous en donnent un aperçu.

1. Dans le fichier d'implémentation WInterrupts.c G pour cartes à cœur AVR, on trouve plusieurs directives #warning, notamment :

#if EXTERNAL_NUM_INTERRUPTS > 8
  #warning There are more than 8 external interrupts. Some callbacks may not be initialized.

Codée dans la déclaration d'un tableau de pointeurs de fonctions à appeler en cas d'interruption, elle avertit l'utilisateur du code que ce tableau ne sera pas complètement initialisé si la pseudo‑constante EXTERNAL_NUM_INTERRUPTS est supérieure à 8.
2. Dans le fichier d'implémentation HardwareSerial0.cpp G pour cartes à cœur AVR, on trouve plusieurs directives #error, notamment à la ligne nº 46 :

#if defined(USART_RX_vect)
  ISR(USART_RX_vect)
#elif defined(USART0_RX_vect)
  ISR(USART0_RX_vect)
#elif defined(USART_RXC_vect)
  ISR(USART_RXC_vect) // ATmega8
#else
  #error "Don't know what the Data Received vector is called for Serial"
#endif

Cette directive déclenche une erreur de compilation si aucune des trois pseudo‑constantes USART_RX_vect, USART0_RX_vect ou USART_RXC_vect n'est définie.