On Tuesday 12 July 2005 15:43, Marty Kraimer wrote:
The following can be defined:
menu(invalidAction) {
choice(invalidActionContinue_normally,"Continue normally")
choice(invalidActionDon_t_drive_outputs,"Don't drive outputs")
choice(invalidActionSet_output_to_IVOV,"Set output to IVOV")
}
struct(invalidOutput, type {
field(invalidAction,menu(menuIvoa))
field(invalidValue,Value)
}
And then the record.dbd would be
field(invalidOutput,struct(invalidOutput,float64))
field(output,device(none,processInvalidOutput))
Fine. Do we agree that we may need more than one type parameter in
struct definitions? (Although it will probably not be very common). The
following should be allowed (for n >= 0):
struct(structName, type_var_1, type_var_2, ..., type_var_n) {
...
}
and then in a record type definition
field(fieldName,struct(structName, type_1, ..., type_n))
And the interface definittion becomes
Some .h file contains:
class processInvalidOutput {
virtual void compute(invalidOutput<epicsInt32>
&output,,epicsString &status, epicsInt16 &severity);
virtual void compute(invalidOutput<epicsInt32>
&output,,epicsString &status, epicsInt16 &severity);
... // perhaps other types for value
}
Assuming you meant to write 'invalidOutput<epicsFloat64>' in one of the
two methods above, this still falls short of a real templatized
version:
class processInvalidOutput {
template <typename ValueType>
void compute(invalidOutput<ValueType>&output, epicsString &status,
epicsInt16 &severity);
}
I have no
idea what happens if the reference is used to overwrite the value
field; maybe the compiler disallows it but then generality suffers,
i.e. you cannot use the struct/template/device-whatever for numeric
types other than the ones you provide definitions for.
Templatizing the method leads to more predictable behavior (no
conversions). However, it also has some disadvantages:
o Compiler error messages can become somewhat lengthy and obscure.
OTOH, I rather get a confusing and hard to decipher error message
from the compiler than strange behavior at run-time.
o More serious: it depends on the implementation of the (templatized)
method, which types are actually allowed in instances. For instance,
if a '<' operator is used on the value, compilation will fail if
instantiated with a type that has no operator '<' defined.
I am uncertain how much of a problem the latter problem is going to be
in practice. If someone wants to instantiate such a template for an
unexpected type and the compiler complains, the record type designer is
free to provide the expected operations (for instance, an operator
'<'). If that is impossible or just impractical, the instantiation
probably doesn't make sense anyway. I still don't like it, because it
means I must take back my claim that I can give a C==-independent
self-contained definition of what type parameters in the DBD file mean.
Hmmm.
