Todos los posts del blog

Los posts publicados hasta la fecha en el blog son, de más recientes a más antiguos:

mp-units v2 - Biblioteca de magnitudes y unidades físicas

Sobre este artículo

     Tiempo estimado de lectura: 20 minutos
     Nivel: Intermedio
     Última actualización: 07 de mayo, 2026

1. Introducción y terminología

Imagen generada con inteligencia artificial. Uso con fines divulgativos

En entornos científicos y tecnológicos, el manejo implícito de unidades físicas es una fuente constante de errores que puede derivar en fallos críticos y grandes costes operativos. En C++, adoptar un sistema de tipado fuerte para magnitudes puede permitir que el compilador actúe como un motor de verificación, detectando inconsistencias dimensionales y resolviendo la lógica de conversión de unidades antes de que tenga lugar la ejecución. Este enfoque logra la seguridad sin penalización en el rendimiento (zero-overhead abstraction [1]), generando un código binario tan eficiente como si se hubiesen empleado tipos numéricos fundamentales desprotegidos (típicamente double), pero eliminando peligrosos errores de magnitudes en tiempo de ejecución.

Reflexión en C++26 (Parte 1)

Lecturas de la serie

• Parte 1: Operador de reflexión ^^ y splicers [:...:]. Sentencias de expansión (template for).
• Parte 2: Anotaciones para reflexión. [Por publicar]
• Parte 3: Generación de agregados (define_aggregate). Bloques consteval.  [Por publicar]
• Parte 4: Sustitución (substitute) y extracción (extract). [Por publicar]

Sobre este artículo

     Tiempo estimado de lectura: 30 minutos
     Nivel: Intermedio-avanzado (metaprogramación, constexpr/consteval, std::expected)
     Última actualización: 28 de abril, 2026

1. Introducción: operador de reflexión ^^ y splicers [:…:]

Esta serie de artículos busca introducir al lector en las nuevas capacidades de reflexión estática que formarán parte del próximo estándar ISO C++26, tal y como fueron introducidas en la propuesta P2996 [1] y que ya han sido incorporadas (con algunas modificaciones y extensiones [2-7]) al draft del estándar [8]. Por reflexión estática entendemos aquí la capacidad de un programa de analizar su propia estructura durante la compilación —a diferencia de la reflexión en tiempo de ejecución de lenguajes como Java o Python— y de generar código derivado de dicha información.

Esta nueva funcionalidad constituye uno de los avances más significativos en la evolución reciente del lenguaje, al ampliar de manera sustancial las capacidades de meta-programación disponibles para el desarrollador. Se fundamenta en los siguientes principios:

1. La representación de elementos del programa mediante expresiones constantes (constant‑expressions) que producen valores de reflexión —reflexiones— del tipo opaco std::meta::info.
2. El operador unario de reflexión (prefijo ^^), capaz de proyectar múltiples construcciones gramaticales del lenguaje a sus correspondientes reflexiones. Se contemplan aquí namespace-names, type-ids, id-expressions (variables, funciones, datos miembro estáticos y no estáticos, plantillas y miembros de plantillas, enumeradores) y el espacio de nombres global ::. El operador ^^ produce prvalues de tipo std::meta::info.
3. Un amplio conjunto de operaciones consteval en la cabecera <meta> para trabajar con dichas reflexiones (incluyendo la derivación de otras reflexiones).
4. Los denominados splicers [: refl :], que permiten generar elementos gramaticales a partir de reflexiones (donde refl debe ser una expresión constante de tipo std::meta::info).

Podemos entender este sistema como una interacción entre dos dominios: el dominio del programa (tipos, miembros, expresiones, etc.) y el meta-dominio formado por los valores std::meta::info. El operador ^^ proyecta elementos del programa al meta‑dominio, donde pueden inspeccionarse y manipularse (por ejemplo, consultando sus tipos, sus identificadores, sus miembros o sus argumentos de plantilla). Los splicers realizan el movimiento inverso, reintroduciendo (reificando) en el código construcciones derivadas de esas reflexiones. Por supuesto, un splicer no puede expandirse a código arbitrario: siempre deberá producir una construcción bien formada, válida en el contexto gramatical donde aparezca. Esta bidireccionalidad constituye la base de la reflexión estática en C++26.