Pourquoi les règles de la MISRA interdisent-elles l'utilisation de #undef dans un programme ? Si je veux limiter la portée d'une macro, comment le faire sans utiliser la fonction #undef ?
Réponses
Trop de publicités?
En fait, parce que la MISRA est trop paranoïaque et ne fait pas confiance aux programmeurs pour savoir ce qu'ils font :-) Sérieusement, la MISRA tente de prévenir certaines erreurs et est guidée par la conviction que si vous interdisez les constructions de code potentiellement problématiques, la fiabilité du logiciel augmente soudainement. La question de savoir si cela est vrai est un sujet de débat. Dans le cas de #undef La raison probable est qu'une fois qu'une macro est définie, son expansion reste en place et est toujours celle de sa définition. Si vous autorisez #undef l'identifiant peut être réutilisé comme variable, nom de fonction, membre de typedef ou de struct/union, ou même comme macro avec un, gasp, différents l'expansion. C'est un moyen d'empêcher l'identification par l'ombre, si vous voulez. Effrayant, n'est-ce pas ? ! Vous décidez !
Pour répondre à votre deuxième question, le seul moyen de limiter la portée d'une macro si #undef ne peut pas être utilisé est d'utiliser la fin du fichier, qui est le seul autre moyen défini par la norme pour terminer la portée d'une macro. En d'autres termes, vous devez diviser vos fichiers sources en fichiers plus petits et définir la macro uniquement lors de la compilation du fichier particulier où elle est nécessaire.
ouah
Points
75311
Andrew
Points
496
En réponse au commentaire de @Bubble ci-dessus :
Je vous demande de donner un exemple à ce sujet. Je ne peux pas imaginer comment cela peut créer de la confusion ?
Imaginez le scénario...
#define MACRO some-definition
.
.
MACRO // Invocation 1
.
.
MACRO // Invocation 2
.
.Et puis quelqu'un arrive et insère, entre les invocations existantes de MACRO
.
.
#undef MACRO
#define MACRO something-else
MACRO // Between (1) and (2)
.
.La deuxième invocation originale de MACRO ne fera pas ce que vous attendiez !
