To define a new Parameter type Parameter<pType> the application designer has to provide a C++ class pType which implements the following methods:
The declaration of a new Parameter type and its operators pType is performed by entering its definition into LISP tables which are processed by the VMAKE CASE utility to generate a new shared library which serves as an MDL Parameter extension library:
(tuple
'(LocParameter::instances
(vClass ( header vAlias scan print instantiate newArg ))
(String ( String String Bool Bool Bool cppConst ))
; ... further parameter types
))
In this table entries into the vClass column denote the C++ class name of the parameter type, header entries define the C++ header files which contain the class declarations, and vAlias is an optional typedef alias for the vClass name. The following entries specify whether the parameter has got valid methods for printing (print) to and scanning (scan) from C++ streams. The instantiate flag determines whether code for the instantiation of the new template class Parameter<pType> will be generated. The column newArg names a C++ constant which will be used as argument for calls to the constructor method of the C++ class pType.
The thereby generated Parameter classes are automatically logged on the Algorithm Library internal parameter sever module which provides services for runtime type checking and instance generation per class name, default value, and link management.
Operators available for parameters of this new type are added to the MDL definition language by supplying further LISP tables with the following structure:
(tuple
'(opTupleName
(resType op1Type op2Type isAlias resAlias op1Alias op2Alias
( left oper right ))
(String String String Bool String String String
( Bool String Bool ))
))
Each MDL operator is designated a table identified by its unique name opTupleName listed in Table 2.1. The only exception is the assignment operator '=' which has to be available for each new parameter type and therefore needs no extra specification. The various combined operators which combine the assignment operator with another operation (e.g. the add and assign operator '+=') are associated to the LISP table of the according normal operator ('+').
Operator Name | Operator | opTupleName |
---|---|---|
array subscripting | '[]' | MDL::op_ArraySubscript |
post increment | '++' | MDL::op_unaryPostInc |
post decrement | '-' | MDL::op_unaryPostDec |
preincrement | '++' | MDL::op_unaryPreInc |
predecrement | '-' | MDL::op_unaryPreDec |
unary minus | '-' | MDL::op_unaryMinus |
unary plus | '+' | MDL::op_unaryPlus |
not | '!' | MDL::op_unaryNot |
multiply | '*' | MDL::op_mult |
divide | '/' | MDL::op_div |
modulo (remainder) | '%' | MDL::op_remainder |
add | '+' | MDL::op_plus |
subtract | '-' | MDL::op_minus |
shift left | '<<' | MDL::op_shiftLeft |
shift right | '>>' | MDL::op_shiftRight |
less than | '<' | MDL::op_less |
less than or equal | '<=' | MDL::op_lessEqual |
greater than | '>' | MDL::op_greater |
greater than or equal | '>=' | MDL::op_greaterEqual |
equal | '==' | MDL::op_equal |
not equal | '!=' | MDL::op_notEqual |
bitwise AND | '&' | MDL::op_bitAnd |
bitwise exclusive OR | '' | MDL::op_bitEOr |
bitwise inclusive OR | '|' | MDL::op_bitIOr |
logical AND | '&&' | MDL::op_logicalAnd |
logical inclusive OR | '||' | MDL::op_logicalIOr |
cast operator | '<..>' | MDL::op_cast |
simple assignment | '=' | |
multiply and assign | '*=' | MDL::op_mult |
divide and assign | '/=' | MDL::op_div |
remainder and assign | '%=' | MDL::op_remainder |
add and assign | '+=' | MDL::op_plus |
subtract and assign | '-=' | MDL::op_minus |
shift left and assign | '<<=' | MDL::op_shiftLeft |
shift right and assign | '>>=' | MDL::op_shiftRight |
bitwise AND and assign | '&=' | MDL::op_bitAnd |
inclusive OR and assign | '|=' | MDL::op_bitIOr |
exclusive OR and assign | '=' | MDL::op_bitEOr |
Table 2.2 lists the meanings of the various columns in these tables. Entries which are not necessary or have no valid value are represented by the LISP constant NIL. Boolean entries with true values are specified with true. The remaining entries are strings enclosed in pairs of quotes ("") specifying the according C++ names.
Note that operators which are not available for a specific parameter type are simply not listed in the table associated with the operator. In case a specific operator is not available with any of the newly defined Parameters the whole LISP table can be omitted.
Column Name | Description |
resType | C++ class name and MDL type of the resulting parameter type |
op1Type | C++ class name and MDL type of the operand to the left of the operator or NIL; For array subscript operator it specifies the array parameter type. |
op2Type | C++ class name and MDL type of the operand to the right of the operator or NIL; For array subscript operators it specifies the type of the index argument. |
isAlias | true if another MDL operator with equal entries for resAlias, op1Alias, and op2Alias but with at least one difference in the related resType, op1Type, and op2Type fields is already defined. This entry is necessary to avoid linker errors caused by doubly defined symbols in the thereby generated Parameter libraries. Such typedef expressions make it possible to declare different Parameter types on the basis of only one C++ class implementation. These types will be distinguished by the type checking mechanisms of the Algorithm Library. |
resAlias | original C++ class name of resType if resType is defined by typedef resAlias resType; |
op1Alias | original C++ class name of op1Type if op1Type is defined by typedef op1Alias op1Type; |
op2Alias | original C++ class name of op2Type if op2Type is defined by typedef op2Alias op2Type; |
left | Has to be true for binary operators and NIL for unary postfix operators. This entry is insignificant for cast and array subscript operators, therefore NIL should be chosen. |
oper | gives the C++ syntax for the operator, e.g. "-"; This entry is insignificant for cast and array subscript operators, therefore NIL should be chosen. |
right | should be true for binary operators and NIL for unary prefix operators. This entry is insignificant for cast and array subscript operators, therefore NIL should be chosen. |