El secreto de las macros de C++: por qué se necesitan do-while(0) y if-else en las macros y 3 errores fatales

Macros en C++: ¿belleza peligrosa o mal necesario?

Cualquiera que haya escrito en C++ al menos una vez se ha topado con macros. Por un lado, son una herramienta poderosa para la metaprogramación que puede reducir la cantidad de código repetitivo. Por otro lado, las macros son famosas por su carácter traicionero. Basta con omitir un punto y coma o colocar mal los paréntesis, y el código se convierte en un monstruo impredecible.

Pero en el mundo de C++ existe una categoría especial de macros que se ve francamente extraña. ¿Alguna vez ha visto un código como este?

#define SAFE_DELETE(ptr) do { delete (ptr); (ptr) = nullptr; } while(0)

Parece lógico: eliminar el puntero y ponerlo a nullptr. Pero, ¿para qué sirve este do-while(0) sin sentido? ¿Un bucle que se ejecuta garantizadamente una sola vez? Parece una redundancia que roza el absurdo. O este otro ejemplo con if-else:

#define LOG_ERROR(msg) if (g_logging) std::cerr << (msg)

Parece que todo es simple. Pero aquí es exactamente donde se esconden los rastrillos con los que han tropezado miles de desarrolladores. Esta pregunta en Stack Overflow ha acumulado decenas de miles de visitas, y hoy analizaremos por qué estas construcciones no son un error, sino una característica, y qué errores de macros de C++ previenen.

¿Por qué las macros no son funciones? El problema principal

Antes de sumergirnos en los entresijos de do-while(0), recordemos en qué se diferencia una macro de una función normal. En C++, una macro es una sustitución de texto. El preprocesador simplemente copia el cuerpo de la macro en el lugar donde se invoca. Sin comprobaciones de tipos, sin ámbitos de visibilidad: puro reemplazo de cadenas.

Es precisamente por esto que surgen los clásicos errores en las macros de C++. Veamos un ejemplo simple:

#define SQUARE(x) x * x\n\nint main() {\n    int a = 5;\n    int result = SQUARE(a + 1); // Esperamos 36, obtenemos 11\n    std::cout << result; // Imprimirá 11\n    return 0;\n}

¿Qué ha pasado? La macro se expandió a a + 1 * a + 1. Debido a la precedencia de operadores, la multiplicación se ejecutó antes que la suma. Primer error: falta de paréntesis. Lo corregimos:

#define SQUARE(x) ((x) * (x))

Ahora funciona. Pero esto es solo el principio. Los problemas reales comienzan cuando la macro contiene varias sentencias o construcciones de control.

El idioma do-while(0): escudo contra catástrofes sintácticas

Volvamos a nuestro SAFE_DELETE. ¿Por qué no escribir la macro de forma más simple, sin este extraño bucle?

#define SAFE_DELETE(ptr) delete (ptr); (ptr) = nullptr;

Parece lógico. Pero imagine que lo usa en este contexto:

if (ptr != nullptr)\n    SAFE_DELETE(ptr);\nelse\n    std::cout << "Pointer is null";

Después de la sustitución, el preprocesador lo convertirá en:

if (ptr != nullptr)\n    delete (ptr);\n    (ptr) = nullptr;\nelse\n    std::cout << "Pointer is null";

¡Y ahí está el error! else ya no pertenece al if, porque ha aparecido una segunda sentencia entre ellos. El compilador dará un error, pero la idea está clara: la macro «rompió» la construcción de control. Precisamente para estos casos se necesita do-while(0). Convierte varias sentencias en una compuesta, manteniendo la lógica:

if (ptr != nullptr)\n    do { delete (ptr); (ptr) = nullptr; } while(0);\nelse\n    std::cout << "Pointer is null";

Ahora todo funciona correctamente. El idioma de macros do-while(0) es un truco estándar que garantiza que la macro se comporte como una sola sentencia.

¿Por qué exactamente do-while(0) y no simplemente un bloque { }?

¡Buena pregunta! Podríamos usar simplemente llaves:

#define SAFE_DELETE(ptr) { delete (ptr); (ptr) = nullptr; }

Intentemos usar