Entrevista técnica de C++: ¿Cómo evaluar la reflexión estática de C++26 sin tratar una propuesta como una ABI estable?

Prompt y contexto

Un equipo quiere la reflexión estática de C++26 para eliminar ramas escritas a mano para nombres de enums, verificaciones de configuración y serialización. El candidato debe explicar el modelo WG21 P2996R13, cómo la metainformación en tiempo de compilación participa en la instanciación de plantillas y cómo realizar entregas mientras el soporte del compilador sea incompleto. Una respuesta sólida separa la propuesta del lenguaje, el código generado y la compatibilidad de ABI.

Qué evalúa el entrevistador

• Si el candidato sabe que P2996 es una propuesta de WG21, no una característica de compilador universal y estable.
• Si distingue entre reflexión en tiempo de compilación, información de tipos en tiempo de ejecución y macros de texto.
• Si puede explicar la reinyección de entidades reflejadas en declaraciones, incluidos el control de acceso y el costo de instanciación.
• Si reconoce los riesgos de ABI entre compiladores, diseño de memoria (layout) y símbolos generados.
• Si puede proponer un respaldo comprobable en lugar de presentar la sintaxis como la solución.

Preguntas aclaratorias para hacer primero

1. ¿Qué compilador, biblioteca estándar, nivel de lenguaje e interruptores de características (feature switches) son compatibles?
2. ¿El código generado se utiliza solo en tiempo de compilación o el proceso debe cargar tipos desconocidos en tiempo de ejecución?
3. ¿El artefacto debe mantenerse estable entre diferentes compiladores, bibliotecas compartidas o lenguajes?
4. ¿La reflexión debe exponer metadatos de solo lectura o generar acceso a miembros, serialización y funciones de validación?
5. ¿Qué presupuestos existen para el tiempo de compilación, el tamaño del binario y los diagnósticos?

Una respuesta de 30 segundos

“P2996R13 describe la reflexión estática en tiempo de compilación: un valor de reflexión enumera tipos y miembros durante la compilación, y luego la sintaxis de empalme (splicing) puede generar declaraciones. No es un escáner en tiempo de ejecución y no promete una ABI compatible entre compiladores. Yo fijaría una matriz de soporte de compiladores, mantendría la reflexión dentro de un límite de generación de código fuente, conservaría respaldos manuales o generados y probaría la semántica, el diseño de memoria y el costo de compilación. La ABI pública sigue siendo una interfaz explícita; los detalles de implementación no deben filtrarse a través de diseños de memoria reflejados”.

Respuesta detallada paso a paso

1. Separar tres modelos de reflexión

La reflexión en tiempo de ejecución consulta tipos mientras se ejecuta un programa. RTTI expone una forma limitada de información dinámica de tipos. La reflexión estática trata los metadatos como una entidad en tiempo de compilación. P2996 apunta a permitir que el compilador recorra tipos, miembros y atributos durante la evaluación de constantes y produzca declaraciones ordinarias de C++. No puede hacer que un binario ya desplegado descubra una nueva clase.

2. Mostrar la intención de la propuesta con sintaxis

Lo siguiente es conceptual; la implementación exacta debe coincidir con la revisión de la propuesta admitida por el compilador. ^^ obtiene información de reflexión y [: ... :] empalma un resultado de reflexión nuevamente en una declaración. Estos tokens no deben presentarse como sintaxis de producción aceptada por todas las cadenas de herramientas.

enum class Color { red, green, blue };

consteval auto names() {
  constexpr auto r = ^^Color;
  // Pseudocode: enumerate members and build a compile-time string table.
  return make_enum_name_table(r);
}

constexpr auto color_names = names();

El punto clave de la entrevista es el flujo de datos: el compilador crea metadatos, las plantillas o funciones constantes los procesan y el artefacto final sigue siendo funciones y datos estáticos ordinarios.

3. Explicar el empalme de declaraciones y los límites de acceso

El empalme (splicing) puede colocar un tipo o miembro reflejado nuevamente en una declaración, pero no elude el control de acceso, el tiempo de vida ni la comprobación de tipos. El acceso a miembros generado sigue obedeciendo las reglas de private, protected, clase base y búsqueda de nombres. Convertir un miembro privado inaccesible en un campo serializado público cambia el contrato de seguridad.

4. Estimar el costo de plantillas y compilación

Un grafo de tipos grande puede instanciar la lógica de reflexión repetidamente en muchas unidades de traducción, aumentando el tiempo de compilación y el ruido en los diagnósticos. Mantenga la reflexión detrás de un único límite de generación, almacene en caché las tablas generadas y mida el pico de memoria con compilaciones incrementales. No envuelva cada plantilla de negocio en reflexión hasta que demuestre que el código duplicado y el costo de mantenimiento realmente disminuyen.

5. Mantener la ABI separada del código generado

El orden de los campos reflejados, los nombres y el diseño de memoria pueden cambiar con el compilador, la biblioteca estándar o la revisión de la propuesta. Las interfaces entre bibliotecas compartidas deben utilizar DTOs estables, serialización versionada y símbolos explícitos; la reflexión debe generar adaptadores del lado de la implementación. Modificar un miembro privado no debe alterar accidentalmente la ABI pública.

6. Diseñar una matriz de respaldo de compiladores

Utilice la detección de capacidades u opciones de compilación para seleccionar entre la reflexión y las implementaciones manuales, pero asegúrese de que ambas compartan las mismas pruebas de comportamiento. La integración continua (CI) debe cubrir un compilador experimental con soporte para la propuesta, la cadena de herramientas estable y una compilación con la reflexión deshabilitada. Registre las versiones del compilador y de la biblioteca, los modificadores de características, los hashes de generación y las verificaciones de interfaz binaria en cada artefacto.

Respuesta de muestra de alta calidad

“Evaluaría P2996R13 como una capacidad del lenguaje en tiempo de compilación. Convierte tipos y miembros en metadatos en tiempo de compilación y utiliza plantillas y empalmes para producir declaraciones ordinarias; no es un escáner de clases en tiempo de ejecución y no resuelve la ABI entre compiladores. El ejemplo de ^^ y empalme debe validarse únicamente en una cadena de herramientas que admita explícitamente la revisión de la propuesta. En producción, mantendría la reflexión detrás de un límite de generación interno, usaría DTOs estables y formatos versionados para interfaces públicas, y conservaría un respaldo manual. La matriz de pruebas compara nombres de enums, bytes serializados, comportamiento ante errores, tiempo de compilación y símbolos públicos antes de habilitarla gradualmente”.

Errores comunes

• Llamar a la propuesta un estándar ampliamente distribuido → el soporte del compilador y las revisiones difieren → fije versiones y mantenga un respaldo.
• Tratar la reflexión estática como un sistema de plugins en tiempo de ejecución → los metadatos en tiempo de compilación no pueden descubrir tipos posteriores al despliegue → utilice un protocolo de registro explícito para plugins.
• Dejar que la reflexión defina el diseño de memoria público → los cambios en los miembros pueden contaminar la ABI → aísle el código de implementación generado detrás de DTOs estables.
• Ignorar el control de acceso → un generador no puede leer legalmente miembros privados arbitrarios → haga que la exposición de campos sea un trait o política explícita.
• Fijarse únicamente en la reducción de líneas de código → la instanciación de plantillas puede ralentizar las compilaciones → mida el tiempo, la memoria y el tamaño del binario.

Preguntas de seguimiento y respuestas

¿En qué se diferencia esto del código generado por macros?

Las macros reemplazan tokens de forma léxica y carecen de semántica de tipos y de búsqueda de nombres normal. La reflexión estática procesa metadatos después de que el compilador comprende el tipo, por lo que puede reutilizar el sistema de tipos y la evaluación de constantes. Todavía depende del soporte del compilador y del costo de compilación, y ninguno de los dos mecanismos crea extensión en tiempo de ejecución por sí mismo.

¿Cómo generaría un mapa de enum a cadena?

Refleje los miembros del enum y genere un arreglo o tabla de búsqueda en tiempo de compilación, con una rama unknown explícita para valores subyacentes no válidos. Pruebe cada miembro, enteros fuera de rango, la política de nombres duplicados y el resultado de respaldo; la conversión a cadena no garantiza compatibilidad de protocolos.

¿Cómo verificaría la coherencia entre compiladores?

Introduzca la salida generada en las mismas pruebas de referencia (golden tests) y compare los bytes serializados, los códigos de error y los símbolos públicos en lugar de la representación de metadatos interna. Fije la revisión de la propuesta por compilador y recurra al código escrito a mano con una advertencia visible cuando la matriz falle.

¿Cuándo debería evitarse la reflexión estática?

Evítela cuando se requiera la carga en tiempo de ejecución de módulos desconocidos, la ABI pública deba ser duradera, la cadena de herramientas no se pueda fijar o la reflexión ahorre unas pocas líneas pero aumente sustancialmente el costo de compilación. El registro explícito, un generador de código o un adaptador escrito a mano son más fáciles de auditar.