Étendre le préprocesseur C avec des macros pratiques
Sommaire
En bref
- Un développeur décrit son implémentation personnalisée du préprocesseur C avec des extensions utilitaires.
- Les trois principales : __print() pour déboguer l'expansion des macros, __where() pour localiser leur définition, et __map() pour appliquer une transformation à chaque argument sans récursion.
- Le débat HN porte sur l'intérêt de standardiser ces améliorations et sur les limites du préprocesseur face à des besoins de métaprogrammation plus ambitieux.
Ce que dit la source
L'auteur explique que le préprocesseur C standard force les développeurs à utiliser du code très verbeux pour des opérations courantes. Travailler avec les macros variadic (__VA_ARGS__) demande d'épuisantes contorsions syntaxiques, particulièrement pour compter les arguments ou appliquer une macro à chaque élément d'une liste. Son extension du préprocesseur offre des raccourcis pour ces motifs récurrents, rendant le code source plus lisible et les expansions plus rapides.
- __print() et __where() servent respectivement à afficher l'expansion d'une macro et à localiser sa définition, simplifiant le débogage sans dumper toute l'unité de traduction
- __map(macro, ...) applique une macro à chaque argument en un seul passage linéaire, éliminant le besoin de fausses récursions avec des macros numérotées (MAP_1, MAP_2, ..., MAP_8) et permettant un nombre arbitraire d'éléments
- __VA_COUNT__ fournit directement le nombre d'arguments variadic, évitant le motif NARG(...) complexe utilisé pour surcharger une macro selon son arité
- C29 ajoutera __COUNTER__, et l'auteur espère que __VA_COUNT__ et __CAT__ (concaténation de jetons) suivront dans une future révision du standard
Dans les commentaires
Débat partagé : les commentateurs reconnaissent l'intérêt pratique des extensions, mais le fil reste petit et ne converge pas sur une demande claire d'adoption. Certains évoquent des alternatives standard ou en cours de normalisation.
- Plusieurs commentateurs mentionnent que ces motifs (NARG, CAT, MAP) se réinventent constamment ; l'un d'eux signale qu'une proposition WG14 pour __VA_TAIL__ existe depuis des années mais n'a pas abouti, suggérant que la standardisation de ces raccourcis se heurte à une certaine inertie.
- Une question légitime surgit sur la sémantique d'expansion de __map() : selon qu'on évalue d'abord les arguments ou qu'on les substitue bruts, le résultat peut différer, ce que l'article ne clarifie pas explicitement.
- Un commentateur demande si le préprocesseur pourrait devenir véritablement Turing-complet avec des additions réfléchies, ouvrant une réflexion plus large sur son rôle vs. celui de vrai langage de métaprogrammation.
- Le thread laisse entendre que des solutions ad-hoc existent déjà (repos de macros réutilisables), questionnant l'urgence d'une standardisation.
Alternatives citées : Un dépôt GitHub (map-macro) offre une implémentation réutilisable du __map() sans modification du préprocesseur. La proposition WG14 __VA_TAIL__ et l'implémentation dans ellipsis / slimcc montrent qu'une syntaxe alternative est possible.
Notre lecture
Article intéressant pour les mainteneurs de compilateurs C ou les passionnés de la métaprogrammation préprocesseur, mais sans conséquence directe pour une équipe DSI ou pour la majorité des développeurs C. L'auteur expose un problème réel (la verbosité des macros variadic) et propose des solutions locales crédibles. Le débat HN confirme que ce sont des motifs bien connus, mais aussi que la standardisation reste bloquée par des freins politiques ou techniques non adressés par cet article. Utile pour la niche de ceux qui écrivent des compilateurs, à ignorer sinon.