¿Por qué usar sentencias do-while y if-else aparentemente sin sentido en macros?

En muchas macros C / C ++, veo el código de la macro envuelto en lo que parece un do whilebucle sin sentido . Aquí hay ejemplos.

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

No puedo ver lo que do whileestá haciendo. ¿Por qué no escribir esto sin él?

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

Los do ... whiley if ... elseestán ahí para que el punto y coma después de la macro siempre signifique lo mismo. Digamos que tenías algo así como tu segunda macro.

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

Ahora, si fuera a usar BAR(X);en una if ... elsedeclaración, donde los cuerpos de la declaración if no estuvieran envueltos entre llaves, obtendría una mala sorpresa.

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

El código anterior se expandiría en

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

que es sintácticamente incorrecto, ya que lo demás ya no está asociado con el if. No ayuda envolver cosas en llaves dentro de la macro, porque un punto y coma después de las llaves es sintácticamente incorrecto.

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

Hay dos formas de solucionar el problema. El primero es usar una coma para secuenciar declaraciones dentro de la macro sin despojarla de su capacidad para actuar como una expresión.

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

La versión anterior de la barra BARexpande el código anterior a lo que sigue, que es sintácticamente correcto.

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

Esto no funciona si en lugar de f(X)tener un cuerpo de código más complicado que necesita ir en su propio bloque, por ejemplo, para declarar variables locales. En el caso más general, la solución es usar algo como do ... whilehacer que la macro sea una declaración única que toma un punto y coma sin confusión.

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

No tiene que usarlo do ... while, también podría cocinar algo if ... else, aunque cuando se if ... elseexpande dentro de un if ... elseconduce a un " colgar otro ", lo que podría hacer que un problema de colgar existente sea aún más difícil de encontrar, como en el siguiente código .

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

El punto es usar el punto y coma en contextos donde un punto y coma colgante es erróneo. Por supuesto, podría (y probablemente debería) argumentarse en este punto que sería mejor declararlo BARcomo una función real, no como una macro.

En resumen, do ... whileestá ahí para solucionar las deficiencias del preprocesador C. Cuando esas guías de estilo C le dicen que descarte el preprocesador C, este es el tipo de cosas que les preocupan.

Las macros son piezas de texto copiadas / pegadas que el preprocesador colocará en el código original; El autor de la macro espera que el reemplazo produzca un código válido.

Hay tres buenos "consejos" para tener éxito en eso:

Ayuda a que la macro se comporte como un código genuino

El código normal generalmente termina con un punto y coma. Si el usuario ve el código que no necesita uno ...

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

Esto significa que el usuario espera que el compilador produzca un error si el punto y coma está ausente.

Pero la verdadera buena razón es que, en algún momento, el autor de la macro tal vez necesite reemplazar la macro con una función genuina (tal vez en línea). Entonces la macro realmente debería comportarse como tal.

Entonces deberíamos tener una macro que necesite punto y coma.

Producir un código válido

Como se muestra en la respuesta de jfm3, a veces la macro contiene más de una instrucción. Y si la macro se usa dentro de una declaración if, esto será problemático:

if(bIsOk)
   MY_MACRO(42) ;

Esta macro podría expandirse como:

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

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

La gfunción se ejecutará independientemente del valor de bIsOk.

Esto significa que debemos agregar un ámbito a la macro:

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

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

Producir un código válido 2

Si la macro es algo como:

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

Podríamos tener otro problema en el siguiente código:

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

Porque se expandiría como:

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

Este código no se compilará, por supuesto. Entonces, nuevamente, la solución está usando un alcance:

#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) ;
}

El código se comporta correctamente nuevamente.

¿Combina los efectos de punto y coma + alcance?

Hay un modismo C / C ++ que produce este efecto: el bucle do / while:

do
{
    // code
}
while(false) ;

El do / while puede crear un ámbito, encapsulando así el código de la macro, y necesita un punto y coma al final, expandiéndose así en el código que lo necesita.

El bono?

El compilador de C ++ optimizará el ciclo do / while, ya que el hecho de que su condición posterior sea falsa se conoce en el momento de la compilación. Esto significa que una macro como:

#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 expandirá correctamente como

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.
}

y luego se compila y optimiza como

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

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

   // Etc.
}

@ jfm3: tiene una buena respuesta a la pregunta. Es posible que también desee agregar que el lenguaje idiomático también previene el comportamiento involuntario posiblemente más peligroso (porque no hay error) con simples declaraciones 'if':

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

if (test) FOO( baz);

se expande a:

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

que es sintácticamente correcto para que no haya un error del compilador, pero tiene la consecuencia probablemente no intencionada de que siempre se llamará a g ().

Las respuestas anteriores explican el significado de estos constructos, pero existe una diferencia significativa entre los dos que no se mencionó. De hecho, hay una razón para preferir el do ... whilea la if ... elseconstrucción.

El problema de la if ... elseconstrucción es que no te obliga a poner el punto y coma. Como en este código:

FOO(1)
printf("abc");

Aunque omitimos el punto y coma (por error), el código se expandirá a

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

y se compilará en silencio (aunque algunos compiladores pueden emitir una advertencia para el código inalcanzable). Pero la printfdeclaración nunca se ejecutará.

do ... whileLa construcción no tiene ese problema, ya que el único token válido después del while(0)es un punto y coma.

Si bien se espera que los compiladores optimicen los do { ... } while(false);bucles, existe otra solución que no requeriría esa construcción. La solución es usar el operador de coma:

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

o incluso más exóticamente:

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

Si bien esto funcionará bien con instrucciones separadas, no funcionará con casos en los que las variables se construyan y utilicen como parte de #define:

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

Con esto, se vería obligado a usar la construcción do / while.

La biblioteca de preprocesador P99 de Jens Gustedt (sí, ¡el hecho de que tal cosa exista también me dejó boquiabierto !) Mejora la if(1) { ... } elseconstrucción de una manera pequeña pero significativa al definir lo siguiente:

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

La razón de esto es que, a diferencia de la do { ... } while(0)construcción, breaky continuetodavía trabajan en el interior del bloque dado, pero el ((void)0)crea un error de sintaxis si se omite el punto y coma después de la llamada a la macro, que de otro modo saltarse el siguiente bloque. (No hay realmente un problema de "colgar más" aquí, ya que se elseune al más cercano if, que es el de la macro).

Si está interesado en los tipos de cosas que se pueden hacer de manera más o menos segura con el preprocesador C, consulte esa biblioteca.

Por algunas razones, no puedo comentar sobre la primera respuesta ...

¡Algunos de ustedes mostraron macros con variables locales, pero nadie mencionó que no pueden usar cualquier nombre en una macro! ¡Morderá al usuario algún día! ¿Por qué? Porque los argumentos de entrada se sustituyen en su plantilla de macro. Y en sus ejemplos de macros que has utilizar el nombre variabled probablemente más utilizado i .

Por ejemplo cuando la siguiente macro

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

se usa en la siguiente función

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

la macro no usará la variable deseada i, que se declara al comienzo de some_func, sino la variable local, que se declara en el bucle do ... while de la macro.

Por lo tanto, ¡nunca use nombres de variables comunes en una macro!

Explicación

do {} while (0)y if (1) {} elsedeben asegurarse de que la macro se expanda a solo 1 instrucción. De otra manera:

if (something)
  FOO(X); 

se expandiría a:

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

Y g(X)sería ejecutado fuera de la ifdeclaración de control. Esto se evita al usar do {} while (0)y if (1) {} else.

Mejor alternativa

Con una expresión de instrucción GNU (que no forma parte del estándar C), tiene una mejor manera que do {} while (0)y if (1) {} elsepara resolver esto, simplemente usando ({}):

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

Y esta sintaxis es compatible con los valores de retorno (tenga en cuenta que do {} while (0)no lo es), como en:

return FOO("X");

No creo que se haya mencionado, así que considera esto

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

se traduciría a

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

observe cómo i++la macro la evalúa dos veces. Esto puede conducir a algunos errores interesantes.