Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 12 Jul 2005 22:49:45 +0200

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);
  }

One must be very careful in C++ with overloading. If in the above 
example you forget to declare a method for invalidOutput<epicsInt16>, 
the argument will silently be converted/promoted to the next larger 
numeric type, like in C. This might be compiler dependent. 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.

> and the process method calls
>
> pprocessInvalidOutput->compute(invalidOutput,status,severity);

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System