C ++ fonctions exposées au système de scripts - types de paramètres autodescriptifs

Question

Un moteur de règles C ++ définit les règles en XML où chaque règle se résume à « si X, alors Y » où X est un ensemble de tests et Y un ensemble d'actions. Dans le code C ++, utilisable « fonctions » dans les tests / actions sont créées en tant que classe pour chaque « fonction », ayant chacune une méthode « run (args) » ... chacun prend son propre ensemble de paramètres.

Cela fonctionne très bien.

Mais, un outil distinct est voulu sauver les utilisateurs XML artisanat main; le moteur de règles est destiné aux non-programmeurs. L'outil a besoin de connaître toutes les « fonctions » disponibles, ainsi que leurs paramètres d'entrée requis. Quelle est la meilleure façon d'envisager de le faire? Je considérais deux possibilités:

1. Un fichier de configuration décrit les « fonctions » et leurs paramètres, et est lu par l'outil. Ceci est assez facile, et le code C ++ réelle peut l'utiliser pour effectuer la validation des arguments, mais le C ++ et XML ne sont pas garantis pour être en phase - un programmeur pourrait modifier C ++ et oublier de mettre à jour le fichier XML conduisant à des bogues de validation
2. Chaque classe « fonction » a des méthodes qui décrivent. D'une certaine manière l'outil charge les classes C ++ ... ce serait facile dans une réflexion de soutien linguistique, mais messier en C ++, vous auriez probablement construire une DLL spéciale avec tous les « fonctions » ou quelque chose. Ce qui signifie que les frais généraux supplémentaires.

Ce qui est logique étant donné la nature de C ++ en particulier?

EDIT: est le titre descriptif? Je ne peux pas penser à un meilleur.

Answer 1

Il y a une 3ème voie - IDL.

Imaginez que vous avez une application client-serveur, et vous avez un générateur de code qui produit des classes wrapper que vous pouvez déployer sur le client et le serveur afin que l'utilisateur peut écrire une application utilisant l'API client et le traitement se produit sur le serveur .. . c'est un scénario typique RPC et est utilisé dans DCE-RPC, ONC-RPC, CORBA, COM et d'autres.

L'astuce ici est de définir les signatures des méthodes que le client peut appeler, ce qui est fait dans une définition de langue de l'interface. Cela ne doit pas être difficile, mais il est la source de l'API client / serveur, vous exécutez par un générateur et produit les classes C ++ que vous compilez pour le client à utiliser.

Dans votre cas, il semble que le XML est le IDL. de sorte que vous pouvez créer un outil qui prend le XML et produit les en-têtes C ++ décrivant les fonctions que votre code expose. Vous n'avez pas vraiment pour générer les fichiers cpp (vous pouvez), mais il est plus facile de simplement générer les en-têtes, de sorte que le programmeur qui ajoute une nouvelle fonction / paramètre ne peut pas oublier de mettre à jour la mise en œuvre - juste ne compilera pas une fois les en-têtes ont été regénérées.

Vous pouvez générer un en-tête est #include dans les en-têtes de c ++ existants s'il y a bien plus que la définitions de fonction.

- c'est ma suggestion, # 3:. Générer les définitions de vos signatures XML définitives

Answer 2

Il y a une autre façon:

• Ajoutez une contrainte que les types d'arguments soient uniformes dans un appel de fonction.
• définir un nombre maximum d'arguments
• décrire les types et la priorité à savoir double converrts à String mais pas vice-versa

vous avez

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

Et d'autres types de données concrètes comme la chaîne, date, etc.

Avantages:

• Les variations de la signature fixe et régulière
• il est possible de fournir uniquement la signature de type "plus grand" (T)
• fonctionne bien avec des modèles et des ponts linguistiques
• peut mettre en garde l'action f avec 2 paramètres entiers non définies