C ++ funciones expuestas a sistema de scripting - tipos de parámetros auto-describen

Question

A motor de reglas de C ++ define reglas en XML, donde cada regla se reduce a "si X, entonces Y", donde X es un conjunto de ensayos y Y un conjunto de acciones. En código C ++, 'funciones' que puedan utilizarse en pruebas / acciones se crean como una clase para cada 'función', cada uno con una "corrida (args)" método ... cada uno toma su propio conjunto de parámetros.

Esto funciona bien.

Pero, una herramienta separada se quiere ahorrar a los usuarios XML artesanalmente el motor de reglas está dirigido a los no programadores. La herramienta tiene que saber todas las 'funciones' disponibles, así como sus parámetros de entrada requeridos. ¿Cuál es la mejor manera de considerar hacer esto? Consideré un par de posibilidades:

1. Un archivo de configuración se describen las 'funciones' y sus parámetros, y es leído por la herramienta. Esto es bastante fácil, y el código real de C ++ se puede utilizar para llevar a cabo la validación de argumentos, pero aún así el C ++ y XML no están garantizados para estar en sintonía - un programador podría modificar C ++ y se olvide de actualizar el código XML que conduce a errores de validación
2. Cada clase 'función' tiene métodos que lo describen. De alguna manera la herramienta de carga las clases C ++ ... esto sería fácil en un lenguaje de apoyo reflexión, sino más desordenado en C ++, probablemente tendría que construir una DLL especial con todas las 'funciones' o algo así. Lo que significa una carga extra.

Lo que tiene sentido dada la naturaleza de C ++ específicamente?

EDIT: es el título descriptivo? No puedo pensar en una mejor.

Answer 1

Hay una tercera manera - IDL.

Imagínese que tiene una aplicación cliente-servidor, y usted tiene un generador de código que produce clases de envoltura que puede implementar el cliente y el servidor de modo que el usuario puede escribir una aplicación mediante la API de cliente y el procesamiento se produce en el servidor .. . este es un escenario típico de RPC y se utiliza en DCE-RPC, ONC-RPC, CORBA, COM y otros.

El truco aquí es definir las firmas de los métodos que el cliente puede llamar, que se hace en un lenguaje de definición de interfaz. Esto no tiene que ser difícil, pero es la fuente de la API de cliente / servidor, se ejecuta a través de un generador y produce las clases de C ++ que compila para que el cliente utilice.

En su caso, parece que el XML es el IDL. por lo que puede crear una herramienta que lleva el XML y produce las cabeceras de C ++ que describen las funciones que expone su código. En realidad, no tiene que generar los archivos cpp (que podría), pero es más fácil de simplemente generar las cabeceras, por lo que el programador que añade una nueva función / parámetro no se puede olvidar a actualizar la aplicación - simplemente no se compilará una vez que las cabeceras han sido re-generado.

Puede generar una cabecera que se #include en las cabeceras existentes ++ c si hay más allá que sólo las definiciones de funciones.

Por lo tanto - que es mi sugerencia, # 3:. Generar las definiciones de sus firmas XML definitivas

Answer 2

Hay otra manera:

• Añadir una restricción que los tipos de argumentos sean uniformes en una llamada de función.
• definir un número máximo de argumentos
• describir los tipos y la precedencia es decir, converrts double a String pero no viceversa

entonces usted tiene

void f(int a1) .. f(int a1 .. int aN)
void f(double a1) .. f(double a1 .. double aN)
..
void f(T a1) .. 

Y otros tipos de datos concretos como cadena, fecha, etc.

Ventajas:

• Las variaciones en la firma fijas y regulares
• que es posible sólo para proporcionar el "mayor" firma de tipo (T)
• funciona bien con plantillas y puentes de idioma
• puede advertir acción f con los parámetros 2 Integer indefinido