Antes de que el compilador realice el análisis sintáctico o genere código máquina, el preprocesador ha realizado ya una pasada completa sobre el código fuente. Su tarea es la compilación condicional: un mecanismo de sustitución textual que permite incluir o excluir fragmentos de código basándose en condiciones predefinidas. Esto es fundamental para la portabilidad, ya que permite que un mismo código fuente se adapte a diferentes sistemas operativos (Windows, Linux, macOS), arquitecturas de CPU (x86_64, ARM64) o capacidades del compilador.
El preprocesador utiliza macros predefinidas (como _WIN32 o __linux__) que el compilador inyecta automáticamente según el entorno. Sin embargo, para evitar depender de la versión específica de un compilador, el estándar ha evolucionado hacia las Feature Test Macros [C++20], que permiten preguntar si el compilador soporta una característica del lenguaje (como concepts o coroutines) de forma estandarizada. También contamos con __has_include [C++17] para verificar la existencia de cabeceras antes de intentar incluirlas, evitando errores de compilación en entornos donde una dependencia opcional no está presente.
Si utilizas mal estas macros, el riesgo no es solo un error de compilación, sino la introducción de comportamiento indefinido o errores silenciosos. Si condicionas una funcionalidad a una arquitectura específica (como __aarch64__) pero no proporcionas un fallback para otras, el código simplemente no compilará en otros sistemas. Por otro lado, si intentas usar una característica de un estándar moderno basándote en una macro de un compilador específico en lugar de una macro de capacidad de la característica, podrías terminar con código que no compila en un compilador que, siendo más moderno, no utiliza el nombre de macro que esperabas.
#include <iostream>
#include <string_view>
#include <type_traits>
// 1. Detección de arquitectura para definir tipos nativos
#if defined(__x86_64__) || defined(_M_X64)
using NativeWord = unsigned long long;
constexpr std::string_view arch_name = "x86_64";
#elif defined(__aarch64__) || defined(_M_ARM64)
using NativeWord = unsigned long long;
constexpr std::string_view arch_name = "ARM64";
#else
using NativeWord = unsigned int;
constexpr std::string_view arch_name = "Unknown/32-bit";
#endif
// 2. Detección de dependencias opcionales [C++17]
#if __has_include(<format>)
#include <format>
#define HAS_FORMAT 1
#endif
// 3. Detección de soporte para atributos específicos [C++17]
// Usamos una macro para verificar si el compilador entiende el atributo [[nodiscard]]
#if __has_cpp_attribute(nodiscard)
#define ATTRIBUTE_NODISCARD [[nodiscard]]
#else
#define ATTRIBUTE_NODISCARD
#endif
// 4. Uso de Feature Test Macros [C++20] para soporte de Concepts
struct Task {
void execute() const { std::cout << "Ejecutando tarea...\n"; }
};
struct Data {
int value;
};
template <typename T>
ATTRIBUTE_NODISCARD void process_item(T item) {
// Usamos C++20 Concepts si están disponibles para validar en tiempo de compilación
#if defined(__cpp_concepts)
if constexpr (requires(T t) { t.execute(); }) {
item.execute();
} else {
std::cout << "Procesando dato simple: " << item << "\n";
}
#else
// Fallback para estándares antiguos (C++14/17 sin concepts)
// Aquí la validación es manual o mediante SFINAE
if constexpr (std::is_member_function_pointer_v<decltype(&T::execute)>) {
item.execute();
} else {
std::cout << "Procesando dato simple (legacy): " << item << "\n";
}
#endif
}
int main() {
// Detección de Sistema Operativo
#if defined(_WIN32)
std::cout << "OS: Windows\n";
#elif defined(__linux__)
std::cout << "OS: Linux\n";
#elif defined(__APPLE__) && defined(__MACH__)
std::cout << "OS: macOS/iOS\n";
#else
std::cout << "OS: Desconocido\n";
#endif
std::cout << "Arquitectura: " << arch_name << "\n";
std::cout << "Tamaño de NativeWord: " << sizeof(NativeWord) << " bytes\n";
// Uso condicional de std::format
#ifdef HAS_FORMAT
std::cout << std::format("Resultado de formato: {}\n", 42);
#else
std::cout << "Resultado: 42 (sin std::format)\n";
#endif
Task my_task{};
Data my_data{100};
process_item(my_task);
process_item(my_data);
return 0;
}
Análisis del código
El programa utiliza varias capas de abstracción para garantizar su portabilidad y aprovechamiento de características modernas.
Primero, mediante el bloque de detección de arquitectura, definimos NativeWord. Si el compilador detecta __x86_64__ (común en GCC/Clang) o _M_X64 (MSVC), asigna un tipo de 64 bits. Esto es crucial cuando trabajas con alineación de memoria o aritmética de punteros dependiente de la arquitectura.
En la función process_item, aplicamos la diferencia entre Feature Test Macros y macros de compilador. En lugar de preguntar si el compilador es __clang__ para usar concepts, preguntamos por __cpp_concepts. Esto es más robusto: si un nuevo compilador soporta C++20 pero no se llama Clang, el código seguirá usando la rama optimizada de concepts. Dentro de esa rama, usamos if constexpr con una cláusula requires [C++20] para realizar una inspección de tipos en tiempo de compilación. Si el compilador no es C++20, el bloque #else ofrece un fallback que utiliza std::is_member_function_pointer_v para simular la validación de la interfaz.
La macro ATTRIBUTE_NODISCARD demuestra cómo __has_cpp_attribute [C++17] permite escribir código que es compatible con compiladores antiguos que no reconocerían [[nodiscard]] como un atributo válido, evitando errores de sintaxis. Finalmente, la detección de std::format mediante __has_include permite que el programa se compile incluso si el entorno no tiene instalada la librería de formato de C++20, evitando errores de “archivo no encontrado”.
El error frecuente
Un error muy común en equipos que migran de versiones antiguas es intentar detectar la disponibilidad de una característica de lenguaje mediante la versión del compilador, en lugar de usar las macros de capacidad.
// ERROR: Mal enfoque (dependencia del compilador)
#if defined(__clang__) && __clang_major__ >= 12
// Intentar usar una feature de C++20 porque Clang 12 lo soporta
// Pero ¿qué pasa si usamos GCC o un compilador que no sea Clang pero sí soporte C++20?
// El código fallará en compilación en GCC a pesar de que sea compatible.
usar_feature_moderna();
#endif
// CORRECTO: Uso de Feature Test Macros (estándar)
#if defined(__cpp_coroutines)
usar_feature_moderna();
#else
// Fallback seguro
#endif
Este último enfoque es preferible porque las macros de la familia __cpp_ están garantizadas por el estándar ISO para indicar que el compilador implementa esa característica específica, independientemente de si su nombre es GCC, Clang o MSVC. Si estás gestionando dependencias externas, es más limpio pasar tus propias macros desde el sistema de construcción (como CMake con target_compile_definitions) para evitar que el código fuente se llene de lógica de detección compleja que debería resolverse en el paso de configuración.
N° 146