C++ functions exposed to scripting system - self-describing parameter types

Question

A C++ rules engine defines rules in XML where each rule boils down to "if X, then Y" where X is a set of tests and Y a set of actions. In C++ code, 'functions' usable in tests/actions are created as a class for each 'function', each having a "run(args)" method... each takes its own set of parameters.

This works fine.

But, a separate tool is wanted to save users hand-crafting XML; the rules engine is aimed at non-programmers. The tool needs to know all the 'functions' available, as well as their required input parameters. What's the best way to consider doing this? I considered a couple of possibilities:

1. A config file describes the 'functions' and their parameters, and is read by the tool. This is pretty easy, and the actual C++ code can use it to perform argument validation, but still the C++ and XML are not guaranteed to be in sync - a programmer could modify C++ and forget to update the XML leading to validation bugs
2. Each 'function' class has methods which describe it. Somehow the tool loads the C++ classes... this would be easy in a language supporting reflection but messier in C++, probably you'd have to build a special DLL with all 'functions' or something. Which means extra overhead.

What makes sense given the nature of C++ specifically?

EDIT: is the title descriptive? I can't think of a better one.

Answer 1

There's a 3rd way - IDL.

Imagine you have a client-server app, and you have a code generator that produces wrapper classes that you can deploy on client and server so the user can write an app using the client API and the processing occurs on the server... this is a typical RPC scenario and is used in DCE-RPC, ONC-RPC, CORBA, COM and others.

The trick here is to define the signatures of the methods the client can call, which is done in an Interface Definition Language. This doesn't have to be difficult, but it is the source for the client/server API, you run it through a generator and it produces the C++ classes that you compile up for the client to use.

In your case, it sounds like the XML is the IDL. so you can create a tool that takes the XML and produces the C++ headers describing the functions that your code exposes. You don't really have to generate the cpp files (you could) but its easier to just generate the headers, so the programmer who adds a new function/parameter cannot forget to update the implementation - it just won't compile once the headers have been re-generated.

You can generate a header that is #included into the existing c++ headers if there is more there than just the function definitions.

So - that's my suggestion, #3: generate the definitions from your definitive XML signatures.

Answer 2

There is one other way:

• Add a constraint that the argument types be uniform in a function call.
• define some max number of arguments
• describe the types and the precedence i.e. double converrts to String but not vice-versa

then you have

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

And other concrete data types like String, Date, etc.

Advantages:

• Variations in signature fixed and regular
• it's possible to only provide the "biggest" type signature (T)
• works well with templates and language bridges
• can warn action f with 2 Integer parameters undefined