Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 13 Jul 2005 17:46:02 +0200

On Wednesday 13 July 2005 13:49, Marty Kraimer wrote:
> Benjamin Franksen wrote:
> >On Tuesday 12 July 2005 15:43, Marty Kraimer wrote:
> >>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);
> >  }
>
> Yes it does but it is what I think users should see.
>
> The interface has overloaded methods for the types that are
> implemented.
>
> The implementation can use templates so that the algoritm is only
> implemented once.
> The interface shows what types are implemented.

This makes sense if only certain types are allowed. But there are cases 
where the functionality is really polymorphic, i.e. it doesn't care at 
all what the type is. InvalidOutput is such an example and there are 
surely others. It would be a strange move to disallow certain types for 
no technical reasons, but just because we don't want to expose the user 
code to a template based interface. (See however the last remark I made 
below.)

> >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.
>
> But the is no different that any other method or function call.

True.

> >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.
>
> Sounds like you agree with that that presenting full blown templates
> to users is not very nice :-)

No, that is not what I meant to say. Rather the decision of whether or 
not to include templates in C+ interfaces must take their disadvantages 
into account, too. I think there are many situations where presenting a 
template based interface is exactly what is needed.

OTOH, I think we don't need to decide this question here. The developer 
of the (struct based) building block is free to present the interface 
how he/she sees fit. Client code will look the same.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System