Gardes d’inclusion

Les en-têtes incluent souvent d'autres en-têtes. Il est facile qu'un même en-tête se retrouve inclus deux fois dans un fichier source.

Dans ce cas, chaque déclaration qu'il contient apparaît deux fois. Pour des définitions de types comme struct ou typedef, cela provoque une erreur de compilation : un type ne peut pas être défini plus d'une fois.

Supposons que a.h et b.h incluent tous deux types.h. Un fichier source qui les inclut tous les deux se retrouve avec types.h copié deux fois.

Le préprocesseur copie aveuglément le texte des en-têtes. Les définitions de types.h sont donc dupliquées, ce qui déclenche une erreur de redéfinition.

Une protection d'inclusion est une petite astuce du préprocesseur qui permet d'inclure un en-tête plusieurs fois sans danger.

Elle entoure tout l'en-tête d'une condition afin que son contenu ne soit traité que la première fois. Les inclusions suivantes sont entièrement ignorées.

La première fois que l'en-tête est rencontré, TYPES_H n'est pas défini : #ifndef est donc vrai et le contenu est traité. Le #define définit ensuite la macro.

Lors d'une inclusion ultérieure, TYPES_H existe déjà : #ifndef est donc faux et le préprocesseur passe directement à #endif.

Voici un en-tête réaliste dont la protection préserve une définition de type.

Même si de nombreux fichiers incluent point.h directement ou indirectement, la structure Point n'est définie qu'une seule fois par unité de traduction.

La macro de protection doit être unique dans tout votre projet, sinon deux en-têtes pourraient entrer en conflit et se masquer silencieusement.

Une convention courante consiste à dériver le nom du nom de fichier en majuscules : point.h devient POINT_H, et net/socket.h devient NET_SOCKET_H.

Les identifiants qui commencent par un trait de soulignement suivi d'une lettre majuscule, ou qui contiennent deux traits de soulignement consécutifs, sont réservés au compilateur et à la bibliothèque standard.

Évitez les protections comme __POINT_H__. Une forme simple avec un suffixe, comme POINT_H, est sûre et claire.

La plupart des compilateurs modernes prennent en charge #pragma once, une ligne placée au début d'un en-tête et qui assure le même rôle.

Cette solution est plus courte et évite les conflits de noms, mais elle ne fait pas partie de la norme C. Les protections traditionnelles avec #ifndef fonctionnent partout.

Les protections avec #ifndef sont entièrement portables et conformes à la norme, mais elles nécessitent une macro unique pour chaque en-tête.

#pragma once est compact et sans conflit, mais dépend de la prise en charge par le compilateur. Certains projets utilisent les deux : un pragma ainsi qu'une protection classique pour une sécurité maximale.

Une protection d'inclusion empêche les inclusions multiples dans un même fichier source pendant sa compilation.

Elle n'empêche pas un en-tête d'être traité une fois dans chacun des fichiers .c distincts. C'est normal, car chaque fichier source constitue une unité de traduction distincte.

Ajoutez une protection d'inclusion à chaque en-tête que vous écrivez, dès la première ligne. Cela coûte trois lignes et évite toute une catégorie d'erreurs déroutantes.

Même les en-têtes simples peuvent ensuite être inclus indirectement par d'autres, alors les protéger dès le départ vous évite des problèmes.

Vérifiez votre compréhension des protections d'inclusion.

Vous avez appris pourquoi inclure deux fois un en-tête provoque des erreurs de redéfinition et comment une protection d'inclusion les empêche.

Utilisez #ifndef/#define/#endif avec une macro unique, ou #pragma once. Nous allons maintenant voir comment partager des variables entre plusieurs fichiers avec extern.