Pourquoi utiliser des instructions do-while et if-else apparemment dénuées de sens dans les macros?

Dans de nombreuses macros C / C ++, je vois le code de la macro enveloppé dans ce qui semble être une do whileboucle vide de sens . Voici des exemples.

#define FOO(X) do { f(X); g(X); } while (0)
#define FOO(X) if (1) { f(X); g(X); } else

Je ne vois pas ce que ça do whilefait. Pourquoi ne pas simplement écrire cela sans cela?

#define FOO(X) f(X); g(X)

Le do ... whileet if ... elsesont là pour faire en sorte qu'un point-virgule après votre macro signifie toujours la même chose. Disons que vous aviez quelque chose comme votre deuxième macro.

#define BAR(X) f(x); g(x)

Maintenant, si vous deviez utiliser BAR(X);dans une if ... elseinstruction, où les corps de l'instruction if n'étaient pas placés entre crochets, vous obtiendriez une mauvaise surprise.

if (corge)
  BAR(corge);
else
  gralt();

Le code ci-dessus se développerait en

if (corge)
  f(corge); g(corge);
else
  gralt();

ce qui est syntaxiquement incorrect, car le reste n'est plus associé à l'if. Cela n'aide pas à encapsuler les choses entre accolades dans la macro, car un point-virgule après les accolades est syntaxiquement incorrect.

if (corge)
  {f(corge); g(corge);};
else
  gralt();

Il existe deux façons de résoudre le problème. La première consiste à utiliser une virgule pour séquencer les instructions au sein de la macro sans la priver de sa capacité à agir comme une expression.

#define BAR(X) f(X), g(X)

La version ci-dessus de bar BARdéveloppe le code ci-dessus dans ce qui suit, ce qui est syntaxiquement correct.

if (corge)
  f(corge), g(corge);
else
  gralt();

Cela ne fonctionne pas si, au lieu de cela, f(X)vous avez un corps de code plus compliqué qui doit aller dans son propre bloc, par exemple pour déclarer des variables locales. Dans le cas le plus général, la solution consiste à utiliser quelque chose comme do ... whilepour que la macro soit une instruction unique qui prend un point-virgule sans confusion.

#define BAR(X) do { \
  int i = f(X); \
  if (i > 4) g(i); \
} while (0)

Vous n'avez pas besoin de l'utiliser do ... while, vous pouvez également préparer quelque chose avec if ... else, bien que quand il se if ... elsedéveloppe à l'intérieur d'un, if ... elsecela mène à un " balancement d'autre ", ce qui pourrait rendre un problème de balancement d'autre encore plus difficile à trouver, comme dans le code suivant .

if (corge)
  if (1) { f(corge); g(corge); } else;
else
  gralt();

Le point est d'utiliser le point-virgule dans des contextes où un point-virgule pendant est erroné. Bien sûr, on pourrait (et devrait probablement) faire valoir à ce stade qu’il serait préférable de déclarerBAR comme une fonction réelle, et non comme une macro.

En résumé, le do ... whileest là pour contourner les lacunes du préprocesseur C. Lorsque ces guides de style C vous disent de mettre à pied le préprocesseur C, c'est le genre de chose qui les inquiète.

Les macros sont des morceaux de texte copiés / collés que le pré-processeur mettra dans le code authentique; l'auteur de la macro espère que le remplacement produira un code valide.

Il y a trois bons "conseils" pour y parvenir:

Aidez la macro à se comporter comme un code authentique

Le code normal se termine généralement par un point-virgule. Si l'utilisateur affiche le code qui n'en a pas besoin ...

doSomething(1) ;
DO_SOMETHING_ELSE(2)  // <== Hey? What's this?
doSomethingElseAgain(3) ;

Cela signifie que l'utilisateur s'attend à ce que le compilateur produise une erreur si le point-virgule est absent.

Mais la vraie vraie bonne raison est qu'à un moment donné, l'auteur de la macro devra peut-être remplacer la macro par une véritable fonction (peut-être en ligne). Donc, la macro devrait vraiment se comporter comme telle.

Nous devrions donc avoir une macro nécessitant un point-virgule.

Produire un code valide

Comme indiqué dans la réponse de jfm3, parfois la macro contient plus d'une instruction. Et si la macro est utilisée dans une instruction if, ce sera problématique:

if(bIsOk)
   MY_MACRO(42) ;

Cette macro pourrait être étendue comme suit:

#define MY_MACRO(x) f(x) ; g(x)

if(bIsOk)
   f(42) ; g(42) ; // was MY_MACRO(42) ;

La gfonction sera exécutée quelle que soit la valeur debIsOk .

Cela signifie que nous devons avoir à ajouter une portée à la macro:

#define MY_MACRO(x) { f(x) ; g(x) ; }

if(bIsOk)
   { f(42) ; g(42) ; } ; // was MY_MACRO(42) ;

Produire un code valide 2

Si la macro est quelque chose comme:

#define MY_MACRO(x) int i = x + 1 ; f(i) ;

Nous pourrions avoir un autre problème dans le code suivant:

void doSomething()
{
    int i = 25 ;
    MY_MACRO(32) ;
}

Parce qu'il s'élargirait comme:

void doSomething()
{
    int i = 25 ;
    int i = 32 + 1 ; f(i) ; ; // was MY_MACRO(32) ;
}

Ce code ne se compilera pas, bien sûr. Donc, encore une fois, la solution utilise une portée:

#define MY_MACRO(x) { int i = x + 1 ; f(i) ; }

void doSomething()
{
    int i = 25 ;
    { int i = 32 + 1 ; f(i) ; } ; // was MY_MACRO(32) ;
}

Le code se comporte à nouveau correctement.

Combiner les effets point-virgule + scope?

Il existe un idiome C / C ++ qui produit cet effet: La boucle do / while:

do
{
    // code
}
while(false) ;

Le do / while peut créer une portée, encapsulant ainsi le code de la macro, et a besoin d'un point-virgule à la fin, se développant ainsi dans le code qui en a besoin.

Le bonus?

Le compilateur C ++ optimisera la boucle do / while, car le fait que sa post-condition soit fausse est connu au moment de la compilation. Cela signifie qu'une macro comme:

#define MY_MACRO(x)                                  \
do                                                   \
{                                                    \
    const int i = x + 1 ;                            \
    f(i) ; g(i) ;                                    \
}                                                    \
while(false)

void doSomething(bool bIsOk)
{
   int i = 25 ;

   if(bIsOk)
      MY_MACRO(42) ;

   // Etc.
}

se développera correctement

void doSomething(bool bIsOk)
{
   int i = 25 ;

   if(bIsOk)
      do
      {
         const int i = 42 + 1 ; // was MY_MACRO(42) ;
         f(i) ; g(i) ;
      }
      while(false) ;

   // Etc.
}

et est ensuite compilé et optimisé comme

void doSomething(bool bIsOk)
{
   int i = 25 ;

   if(bIsOk)
   {
      f(43) ; g(43) ;
   }

   // Etc.
}

@ jfm3 - Vous avez une belle réponse à la question. Vous voudrez peut-être également ajouter que l'idiome de macro empêche également le comportement involontaire éventuellement plus dangereux (car il n'y a pas d'erreur) avec de simples instructions «si»:

#define FOO(x)  f(x); g(x)

if (test) FOO( baz);

s'étend à:

if (test) f(baz); g(baz);

qui est syntaxiquement correct donc il n'y a pas d'erreur de compilation, mais a la conséquence probablement non voulue que g () sera toujours appelé.

Les réponses ci-dessus expliquent la signification de ces constructions, mais il existe une différence significative entre les deux qui n'a pas été mentionnée. En fait, il y a une raison de préférer le do ... whileà la if ... elseconstruction.

Le problème de la if ... elseconstruction est qu'elle ne vous oblige pas à mettre le point-virgule. Comme dans ce code:

FOO(1)
printf("abc");

Bien que nous ayons omis le point-virgule (par erreur), le code sera étendu à

if (1) { f(X); g(X); } else
printf("abc");

et compilera en silence (bien que certains compilateurs puissent émettre un avertissement pour le code inaccessible). Mais la printfdéclaration ne sera jamais exécutée.

do ... whileLa construction n'a pas un tel problème, car le seul jeton valide après le while(0)est un point-virgule.

Bien qu'il soit prévu que les compilateurs optimisent les do { ... } while(false);boucles, il existe une autre solution qui ne nécessiterait pas cette construction. La solution est d'utiliser l'opérateur virgule:

#define FOO(X) (f(X),g(X))

ou encore plus exotiquement:

#define FOO(X) g((f(X),(X)))

Bien que cela fonctionne bien avec des instructions distinctes, cela ne fonctionnera pas avec les cas où les variables sont construites et utilisées dans le cadre de #define:

#define FOO(X) (int s=5,f((X)+s),g((X)+s))

Avec cela, on serait obligé d'utiliser la construction do / while.

La bibliothèque de préprocesseurs P99 de Jens Gustedt (oui, le fait qu'une telle chose existe m'a aussi fait réfléchir !) Améliore la if(1) { ... } elseconstruction de manière petite mais significative en définissant ce qui suit:

#define P99_NOP ((void)0)
#define P99_PREFER(...) if (1) { __VA_ARGS__ } else
#define P99_BLOCK(...) P99_PREFER(__VA_ARGS__) P99_NOP

La raison en est que, contrairement à la do { ... } while(0)construction, breaket continuefonctionne toujours à l'intérieur du bloc donné, mais ((void)0)crée une erreur de syntaxe si le point-virgule est omis après l'appel de la macro, ce qui autrement ignorerait le bloc suivant. (Il n'y a pas vraiment de problème de "balançoire d'autre" ici, car le elselien au plus procheif , qui est celui de la macro.)

Si vous êtes intéressé par le genre de choses qui peuvent être faites plus ou moins en toute sécurité avec le préprocesseur C, consultez cette bibliothèque.

Pour certaines raisons, je ne peux pas commenter la première réponse ...

Certains d'entre vous ont montré des macros avec des variables locales, mais personne n'a mentionné que vous ne pouvez pas utiliser n'importe quel nom dans une macro! Il mordra l'utilisateur un jour! Pourquoi? Parce que les arguments d'entrée sont substitués dans votre modèle de macro. Et dans vos exemples de macro, vous avez utilisé le nom variable probablement le plus couramment utilisé i .

Par exemple, lorsque la macro suivante

#define FOO(X) do { int i; for (i = 0; i < (X); ++i) do_something(i); } while (0)

est utilisé dans la fonction suivante

void some_func(void) {
    int i;
    for (i = 0; i < 10; ++i)
        FOO(i);
}

la macro n'utilisera pas la variable i prévue, qui est déclarée au début de some_func, mais la variable locale, qui est déclarée dans la boucle do ... while de la macro.

Ainsi, n'utilisez jamais de noms de variables communs dans une macro!

Explication

do {} while (0)et if (1) {} elsedoivent s'assurer que la macro est étendue à une seule instruction. Autrement:

if (something)
  FOO(X); 

s'étendrait à:

if (something)
  f(X); g(X); 

Et g(X)serait exécuté en dehors de la ifdéclaration de contrôle. Ceci est évité lors de l'utilisation de do {} while (0)et if (1) {} else.

Meilleure alternative

Avec une GNU expression de déclaration ( et non une partie de C standard), vous avez une meilleure façon que do {} while (0)et if (1) {} elsepour résoudre ce problème, en utilisant simplement ({}):

#define FOO(X) ({f(X); g(X);})

Et cette syntaxe est compatible avec les valeurs de retour (notez que ce do {} while (0)n'est pas le cas), comme dans:

return FOO("X");

Je ne pense pas que cela ait été mentionné, alors considérez ceci

while(i<100)
  FOO(i++);

serait traduit en

while(i<100)
  do { f(i++); g(i++); } while (0)

remarquez comment i++est évalué deux fois par la macro. Cela peut conduire à des erreurs intéressantes.