Reflexión en tiempo de compilación en C++ 1z? [closed]

4 minutos de lectura

avatar de usuario
Vicente

Hay un grupo de estudio en el comité de estandarización de C++ para proporcionar reflexión en tiempo de compilación en C++1z o posterior. Me gustaría saber cuál es exactamente el propósito y qué tan poderosas serán las herramientas esperadas.

Por ejemplo, ¿será posible nombrar funciones o clases usando estas herramientas?

struct A {int f() {return 42;}};
struct B {int (std::reflect<A>::member<0>::declname)() {return 43;}};
// equivalent to struct B {int f() {return 43;}};

Si no fuera tan poderoso como este, ¿cuáles serían los casos de uso típicos?

  • Todavía está en etapas muy tempranas. Lo mejor que puedes hacer es mira lo que la gente está proponiendo.

    –Joseph Mansfield

    5 de marzo de 2014 a las 18:46

  • @JosephMansfield Ya he buscado, pero como no conozco la “historia” del grupo de estudio, no estoy seguro de entender cuál es “su último sueño”…

    – Vicente

    5 de marzo de 2014 a las 18:48

  • No creo que ellos lo sepan todavía.

    –Joseph Mansfield

    5 de marzo de 2014 a las 18:48


  • Alguien votó en contra de esta pregunta… ¡wtf! Es posible que no agregue nada en la codificación, pero estoy seguro de que no sabía nada sobre el acceso a una enumerator_list desde un static_assert en tiempo de compilación. Esta es una característica impresionante. El futuro se ve brillante

    – Claudiorggz

    5 de marzo de 2014 a las 18:54


  • Esta pregunta parece estar fuera de tema porque se trata de especulaciones. Pertenece a la propuestas estándar foro.

    – R. Martinho Fernández

    21 de agosto de 2014 a las 22:10

avatar de usuario
Andrés Tomazos

Los casos de uso de reflexión se describen en N3814:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3814.html

La vista general es que lo haremos como una extensión de la biblioteca Type Traits como lo ejemplifica N3815:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3815.html

Hay dos partes en la reflexión. El primero es introspección. Tomar una entidad y consultar valores constantes sobre ella. el segundo es cosificaciónque es lo contrario: usar valores para crear nuevas entidades.

Para la introspección, puede esperar rasgos adicionales que le permitirán enumerar y obtener los nombres de los miembros de la clase, las clases base, los enumeradores, los parámetros de función, etc. en tiempo de compilación. Desde allí, puede usarlos para cosas como serialización, operaciones de miembros, comprobaciones estáticas y varias otras cosas.

Además, más adelante veremos la cosificación, lo que implicaría crear nuevas entidades a partir de valores constantes con más expresividad de la que se puede con una plantilla. Así que tal vez podría llenar un std::class_specifier s estructurar y luego llamar make_type_from_spec(s) para crear el tipo.

El enfoque de introspección tiene más consenso en este momento, el lado de la reificación está más alejado.

  • No estoy seguro de lo que llamas “reificación”. ¿Es mi pequeño ejemplo un caso de reificación (¿reinterpretar una cadena en tiempo de compilación como el nombre de una función?)

    – Vicente

    5 de marzo de 2014 a las 18:58

  • El tiempo de compilación es tan valioso como el tiempo de ejecución y tiene el potencial de ser aún más valioso. Boost Static Assert me ha ayudado mucho en el pasado, pero la verificación de concepto, por otro lado, no ha sido fácil de digerir e implementar. Estas características que enumera parecen un gran valor agregado a c ++

    – Claudiorggz

    5 de marzo de 2014 a las 18:58

  • @Vincent: Sí, la creación de una nueva entidad con un nombre que es una cadena de tiempo de compilación, y no un token de identificador, lo considero parte de la cosificación. Creo que podremos leer un identificador (como en N3815) antes de poder escribir uno.

    – Andrés Tomazos

    5 de marzo de 2014 a las 19:00


  • Bien, genial, veo un futuro brillante para el desarrollo de bibliotecas usando introspección+reificación+metaprogramación de plantillas…

    – Vicente

    5 de marzo de 2014 a las 19:03

  • @NoSenseEtAl: Sí. Si observa el código de ejemplo en N3815, puede ver cómo pasar de los rasgos dados a un bucle for sobre los enumeradores de un tipo de enumeración. Actualmente estoy trabajando en rasgos similares para los miembros de la clase, por lo que podrá recorrer los miembros de la clase. Por supuesto, los miembros de la clase tienen tipos heterogéneos, por lo que el “bucle” será como recorrer los elementos de un std::tuple – no puede ser un bucle for como tal – pero podrá obtener el mismo efecto de hacer algo para cada miembro de la clase.

    – Andrés Tomazos

    5 de marzo de 2014 a las 23:15


¿Ha sido útil esta solución?