Introducing complex_plugin
Appropriately, this extended C++ example is called complex_plugin.cpp, and it is also available in the samples\correlator_plugin\cpp directory of the Apama installation. A README.txt file in the directory describes how to build the example plug-in.
This time, the C++ example has three plug-in C++ methods defined:
class ComplexPlugin {
public:
static void AP_PLUGIN_CALL test1(
const AP_Context& ctx,
const AP_TypeList& args,
AP_Type& rval,
AP_TypeDiscriminator);
static void AP_PLUGIN_CALL test3(
const AP_Context& ctx,
const AP_TypeList& args,
AP_Type& rval,
AP_TypeDiscriminator);
static void AP_PLUGIN_CALL test4(
const AP_Context& ctx,
const AP_TypeList& args,
AP_Type& rval,
AP_TypeDiscriminator);
}
ComplexPlugin::test1 dynamically decodes and displays its arguments, and then modifies the contents of any sequences that are passed to it.
ComplexPlugin::test3 allocates and returns an
ExampleChunk opaque object (see
The chunk type for more information on opaque objects).
ComplexPlugin::test4 uses an
ExampleChunk object as created by
ComplexPlugin::test3, modifies and prints its contents, and then returns it.
You may have noticed that no test2 was defined. This is intentional and the reason will become evident shortly.
In order to map the above C++ methods to plug-in functions, you must define the Functions static array. This time this looks as follows:
static const char8* test1ParamTypes[4] =
{"integer", "float", "boolean", "string"};
static const char8* test2ParamTypes[4] =
{"sequence<integer>", "sequence<float>", "sequence<boolean>",
"sequence<string>"};
static const char8* test3ParamTypes[1] = {"integer"};
static const char8* test4ParamTypes[1] = {"chunk"};
static AP_Function Functions[4] = {
{"test1",&ComplexPlugin::test1,4,&test1ParamTypes[0],"string"},
{"test2",&ComplexPlugin::test1,4,&test2ParamTypes[0],"float"},
{"test3",&ComplexPlugin::test3,1,&test3ParamTypes[0],"chunk"},
{"test4",&ComplexPlugin::test4,1,&test4ParamTypes[0],"void"}
};
This definition highlights some of the powerful capabilities available to plug-in developers.
First of all it maps
ComplexPlugin::test1 to the plug-in method
test1, indicates that it takes four EPL parameters, sets these to be an
integer, a
float, a
boolean and a
string respectively, and sets the return type to be a
string.
It then maps
ComplexPlugin::test1 (again!) to the plug-in method
test2, this time indicating that it will take four EPL parameters, and sets these to be a
sequence of
integer, a
sequence of
float, a
sequence of
boolean and a
sequence of
string, respectively. It then sets the return type to be a
float. It is important to note that this multiple mapping of the same C++ method can only be carried out if the method is written with no assumptions regarding the type of its parameters or result. In fact, if you examine the full source code for this example, as provided below, you will see that this method examines the parameters' types before manipulating them.
ComplexPlugin::test3 is mapped to
test3 and set to take a single
integer. Interestingly though, it is set to return a
chunk type. This is a special purpose
opaque type. For an explanation of this type,
The chunk type.
ComplexPlugin::test4 is mapped to
test4, and accepts a
chunk type. Its implementation is designed to work on the
chunk result produced by
ComplexPlugin::test3. It does not return a value.